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作者 简介 


张 开 涛 

现 就 职 于 京东 ，“ 开 涛 的 博客 ”公众 号 作者 。 
写 过 《 跟 我 学 Spring》《 跟 我 学 Spring MVC) 
《 跟 我 学 Shiro 》《 跟 我 学 Nginx+Lua 开 发 》 
等 系列 教程 ， 博 客 现 有 1000 多 万 访问 量 。 
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本 书 总 结 并 梳理 了 亿 级 流量 网 站 高 可 用 和 高 并 发 原则 ， 通 过 实例 详细 介 
绍 了 如 何 落地 这 些 原则 。 本 书 分 为 四 部 分 : 概述 、 高 可 用 原则 、 高 并 发 
原则 、 案 例 实战 ， 从 负载 均衡 、 限 流 、 降 级 、 隅 离 、 超 时 与 重 试 、 回 次 
机 制 、 压 测 与 预案 ` 缓 存 、 池 化 、 有 异步 化 、 扩 容 、 队 列 等 多 方面 详细 地 
fee oup 让 读者 看 完 能 快速 在 实践 中 加 以 
运用 。 

不 管 是 软件 开发 人 员 还 是 运 维 人 员 ， 通 过 阅读 本 书 ， 都 能 系统 地 学 习 实 
0 并 收获 解决 系统 问题 的 思路 和 方 
YE o 

未 经 许可 ， 不 得 以 任何 方式 复制 或 抄袭 本 书 之 部 分 或 全 部 内 容 。 
版 权 所 有 ， 侵 权 必 先 。 
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书评 

本 书 是 保证 大 规模 电 商 系统 在 高 流量 、 高 频次 的 冲击 下 仍 能 正常 运行 的 
葵花 宝典 ， 是 互联 网 一 线 技 术 研 发 人 员 的 实战 手册 。 该 书 是 经 
过 “618”、“ 双 11” 多 次 大 考 ， 在 实践 中 反复 论证 应 运 而 生 的 。 就 如 山野 的 
绿 草 历经 大 自然 千 锤 百 炼 、 风 十 彩虹、 破土 而 出 ， 在 自然 中 寻 得 的 法 
则 。 但 一 切 有 为 的 成 果 都 是 位 勤 努 力 的 结果 ， 我 认识 开 涛 后 重要 的 印象 
之 一 就 是 他 加 班 加 点 ， 挑 灯 夜 战 ， 几 乎 每 天 下 班 都 是 星辰 相伴 ;印象 之 
二 是 他 不 像 传 统 中 的 全 男 ， 而 是 一 个 热情 、 开 衣 、 有 爱心 的 阳光 男 ;， 邱 
象 之 三 是 他 本 身 束 如 他 的 大 作 ， 是 一 个 博学 多 才 的 “字典 *"， 凡 是 技术 性 
的 问题 大 家 都 找 他 请 教 ， 有 问 必 答 。 癌 致力 于 顶级 电 商 系统 建设 的 研发 
人 员 强 烈 推荐 © 


RER 京东 集团 副 总 裁 、 京 东 保险 业务 负责 人 


ZARA BEANE, FOR PASAT EN Dae” AY BF SRI ES, 
今天 的 未 东 技 术 人 有 着 丰富 的 大 流量 应 对 经 验 ， 每 到 大 促 都 期 望 更 猛烈 


的 流量 来 检验 他 们 的 系统 。 作 者 集中 火力 讲述 了 他 在 永 东 构建 大 流量 系 
统 用 到 的 高 可 用 和 高 并 发 原则 ， 并 通过 实际 案例 让 读者 能 落地 。 


马 松 京东 集团 副 总 裁 、 京 东 商 城 研发 体系 负责 人 


近 十 年 来 ， 泵 东 的 业务 规模 在 不 停 驱 动 着 系统 的 升级 送 代 和 技术 创新 ， 
到 今天 ， 泵 东 已 沉淀 了 不 少 技 术 创 新 ， 可 以 说 完成 了 从 使 用 技术 到 创新 
技术 的 转变 。 与 此 同时 ， 泵 东 的 技术 人 在 技术 圈 内 的 影响 力也 在 不 断 扩 
大 ， 开 涛 同学 就 是 泵 东 技 术 的 一 个 好 代表 。 他 在 网 站 系统 升级 六 代 的 过 
程 中 ， 不 断 创 新 和 使 用 新 技术 ， 并 将 多 年 的 实践 和 积累 都 浓缩 到 了 本 书 
中 。 该 书 可 谓 是 当今 电 商 互联 网 圈 内 的 民心 力作 ， 理 论 和 实践 的 完 类 结 
合 ， 满 满 都 是 干货 ， 也 是 京东 技术 人 对 互联 网 技术 圈 的 一 份 贡献 ， 强 烈 
推荐 大 家 阅读 。 


HE 京东 集团 副 总 裁 、 京 东 X 事 业 部 负责 人 


第 一 次 见 到 开 涛 是 在 部 门 的 每 周 例会 上 ， 当 时 束 对 开 涛 留 下 了 深刻 印 
象 ， 说 话 清晰 简洁 ， 分 析 严 谨 透 彻 ， 人 也 长 得 阳光 帅气 。 后 来 才 知 道 他 
在 Java 圈 中 知名 度 很 蜗 ,，“ 开 涛 的 博客 ”浏览 量 过 千 万 ， 古 个 不 折 不 扣 的 技 
术 大 牛 。 本 书 是 开 涛 5 年 多 在 高 可 用 和 高 并 发 方面 总 体 原 则 、 关 键 技术 和 
实战 经 验 的 总 结 ， 还 包括 了 曾经 经 历 的 坑 ， 可 请 是 理论 与 实践 相 结 合 的 
结晶 。 在 经 过 了 “ 泵 东 618”、“ 双 11” 的 亿 级 大 考 后 ， 保 证 了 此 书 足 以 作为 
有 志 于 构建 亿 级 流量 网 站 的 技术 人 员 们 必 备 的 案头 参考 书 。 


杨 建 京东 保险 高 级 研发 总 监 


如 何 构建 高 并 发 、 大 流量 的 系统 ， 不 是 架构 师 闭 门 造 车 想 出 来 的 ， 是 线 
上 实际 的 用 户 流 量 检验 的 。 本 书 通过 大 量 的 实践 案例 ， 告 诉 读者 如 何 染 
构 高 并 发 ， 大 流量 的 网 站 系统 ， 不 光 有 理论 探讨 ， 亦 有 大 量 的 泵 东 实 际 
案例 ， 干 货 多 ， 强 烈 推 荐 研发 人 员 通 读 此 书 。 

王 晓 钟 京东 商城 高 级 研发 总 监 
本 书 内 容 翔 实 ， 将 专业 知识 讲解 得 通俗 易 履 ， 从 前 端 HTML 到 DB 底层 的 
设计 无 不 精细 阐述 。 更 难 能 可 贯 的 是 ， 用 真实 成 功 案例 传授 如 何在 实战 
中 进行 大 流量 网 站 架构 ， 字 里 行 间 都 传递 着 作者 的 经 验 积 索 ， 可 请 字 字 
珠 矶 ， 是 初学 者 的 手册 ， 更 是 技术 大 牛 的 切磋 宝典 。 


HE 京东 商城 研发 总 监 


本 书 站 在 一 个 新 的 高 度 考虑 网 站 后 台 技 术 ， 从 应 用 级 缓存 到 前 端 缓存 、 
从 SOA 到 闭环 等 无 处 不 体现 作者 的 深厚 功 砌 。 作 为 系 东 大 咖 的 作者 结合 
了 在 系 东 的 最 佳 实践 ， 运 用 新 的 网 站 开发 理论 ， 提 出 了 一 套 非常 全 面 的 
大 流量 、 高 并 发 网 站 后 合 的 解决 方案 。 实 践 证 明 这 一 套 方案 特别 有 用 ， 

因为 他 结合 了 最 新 的 开发 技术 ， 人 简化 了 开发 过 程 ， 比 较 全 面 地 考虑 到 了 
可 能 面临 的 问题 。 此 书 特别 适合 中 大 型 网 站 的 架构 师 、 开 发 工程 师 、 运 
维 等 人 员 ， 建 议 人 手 一 本 。 


杨 思 勇 京东 商城 研发 总 监 


首先 ， 这 是 一 个 非常 靠 谱 的 技术 人 写 出 的 非常 靠 谱 的 作品 ， 本 书 作者 是 
泵 东 的 技术 牛人 ， 长 期 战斗 在 研发 的 第 一 线 ， 充 满 京 东 技 术 人 的 理想 与 
激情 。 同 时 ， 本 书 也 是 泵 东 这 么 多 年 高 速 发 展 经 历 的 架构 升级 及 大 促 备 
战 经 验 的 忌 结 ， 将 构建 高 可 用 、 高 并 发 系统 的 各 种 设计 原则 、 技 术 方 
案 、 最 佳 实践 进行 了 全 面 剖 析 ， 知 识 量 非 常 大 ， 值 得 所 有 大 中 型 网 站 架 
构 师 、 开 发 人 员 伦 时 间 学 习 。 


ER FORMA Be 


面 对 大 流量 、 高 并 发 ， 怎 样 让 目 己 开发 的 系统 运行 得 更 高 效 、 展 现 出 更 
好 的 性 能 体验 ? 系统 底层 怎么 构建 、 资 源 怎么 调度 、 流 量 怎 么 管控 ..….……. 
其 实 这 些 在 系统 设计 上 都 是 有 套路 的 ， 能 将 这 种 套路 讲 得 特别 清晰 、 总 
结 得 特别 到 位 的 书 真 的 不 多 ， 此 书 非 常 值得 大 家 一 读 。 


付 彩 宝 京东 商城 研发 总 监 


本 书 着 重 介绍 了 高 并 发 、 高 可 用 服务 的 基本 设计 原则 和 技术 ， 并 辅 以 翔 
实 的 案例 说 明 ， 对 从 业 人 员 有 很 强 的 指导 意义 。 作 者 开 涛 具备 多 年 高 并 
发 高 可 用 服务 经 验 ， 结 合 目 己 的 工作 实践 ， 将 响应 亿 级 请 求 的 商品 详情 
页 系统 的 设计 过 程 完 整 展现 给 读者 ， 干 货 满 满 ， 在 同类 书籍 中 极为 少 
见 ， 具 有 很 强 的 借鉴 意义 ， 强 烈 推 荐 。 


王 春 明 京东 商城 研发 总 监 
本 书 深 入 浅 出 地 介绍 了 高 并 发 系统 的 建设 之 路 ， 是 几 年 实战 经 验 的 沉 
淀 ， 并 且 都 经 过 了 泵 东 大 促 下 大 流量 的 考验 。 不 管 是 初学 者 还 是 资深 的 
染 构 师 都 能 从 中 获取 到 宝贵 经 验 。 开 涛 古 技 术 应 用 于 业务 、 理 论 应 用 于 
实践 的 大 师 。 开 涛 出 品 ， 必 属 精品 。 


何 小 锋 京东 商城 基础 平台 部 首席 架构 师 


大 家 期 竺 已 久 的 《 亿 级 流量 网 站 架构 核心 技术 》 终 于 出 版 了 ， 这 对 于 中 
国 互联 网 界 的 工程 师 们 来 说 真是 一 个 天 大 的 福利 。 该 书 可 谓 理 论 和 实践 
结合 的 最 佳 典范 ， 着 眼 于 高 并 发 和 高 可 用 ， 提 出 了 一 系列 作者 在 实战 中 
总 结 提炼 出 来 的 设计 秘籍 ， 并 通过 案例 对 每 一 条 秘籍 进行 详细 破解 ， 书 
中 提 及 的 每 一 个 案例 均 为 作者 在 工作 中 的 真实 案例 ， 都 经 历 过 大 促 亿 级 
流量 的 考验 ， 全 是 满 满 的 干货 。 该 书 作者 开 涛 同学 热爱 技术 ， 乐 于 分 
享 ， 我 拜读 了 他 所 有 的 博客 和 公众 号 文章 ， 受 花 匪 浅 。 这 是 作者 又 一 次 
民心 出 品 ， 值 得 研读 ， 强 烈 推 荐 。 


者 文明 京东 商城 运营 研发 部 首席 架构 师 


开 涛 负责 的 泵 东 网 站 等 核心 系统 ， 是 永 东 第 一 个 迁移 到 泵 东 弹 性 云 容 器 
平台 运行 的 系统 。 在 上 线 初 期 遇 到 架构 、 性 能 等 问题 ， 开 涛 以 其 扎实 的 
大 流量 网 站 架构 技术 功底， 顺利 保障 第 一 个 核心 系统 上 容 需 化 平台 。 这 
本 《 亿 级 流量 网 站 架构 核心 技术 》， 汇 集 了 开 涛 多 年 在 泵 东 最 核心 的 网 
站 系统 架构 的 演进 和 实践 。 特 别 是 京东 业务 快速 增长 ， 对 网 站 流量 并 发 
带 来 的 挑战 ， 技 术 选 择 ， 架 构 变 章 ， 最 具 实 践 意义 。 这 本 书 结合 实际 的 
案例 ， 生 动 展现 了 技术 发 展 线路 。 如 采 你 正在 应 对 流量 并 发 的 增加 或 者 
系统 架构 需要 变革 的 十 字 路 口 ， 这 本 书 是 你 书桌 上 不 可 缺少 的 理论 和 实 


鲍 永 成 ”京东 商城 容器 引擎 平台 负责 人 


随 着 用 户 规 模 的 增长 ， 网 站 架构 问题 的 难度 也 在 成 倍增 加 。 构 建 一 个 大 
人 网 站 的 技术 架构 难度 截然 不 


在 具体 的 架构 实践 中 ， 所 需要 考虑 的 问题 也 远 比 中 小 型 网 站 多 得 多 。 开 
涛 根据 在 系 东 网 站 架构 工作 期 间 的 实战 经 验 写 成 此 书 。 书 中 既 有 大 型 网 
站 架构 的 通用 原则 ， 也 有 具体 难点 的 解决 方案 和 实践 经 验 。 


最 重要 的 是 ， 书 中 所 述 的 很 多 通用 原则 和 技术 方案 都 在 京东 网 站 线 上 得 
到 了 有 效 使 用 和 验证 。 对 于 想 深 入 了 解 如 何 构建 一 个 大 型 网 站 的 读者 ， 
这 是 一 本 难得 的 好 书 。 


陈锋 ”京东 云 平 台 事 业 部 架构 师 


读 完了 开 涛 的 《 亿 级 流量 网 站 架构 核心 技术 》 原 稿 ， 我 激动 的 心情 难以 
平复 ， 这 正 是 我 一 直 布 望 得 到 的 那 种 指导 手册 式 的 技术 书籍 。 书 中 没有 


浮 肤 的 辞 洛 ， 而 是 实 实在 在 地 展示 了 开 涛 多 年 来 在 实战 中 验证 过 的 理论 


与 经 验 。 


如 果 你 是 一 位 也 面临 着 高 访问 高 并 发 场景 的 研发 人 员 ， 那 么 相信 我 ， 这 
本 书 中 所 描述 的 思路 和 方法 ， 绝 对 值得 你 去 学 习 和 借鉴 。 


赵云 霄 ”京东 商城 ”API 网 关 负 责 人 


本 书 详细 介绍 了 大 流量 、 高 并 发 系统 的 设计 原则 和 具体 实现 方法 。 从 限 
流 降级 到 多 级 缓存 、 有 异步 化 、 服 务 闭 环 ， 对 最 近 几 年 在 高 并 发 领域 大 行 
其 道 的 Nginx+Lua 架 构 的 讲解 更 是 细致 人 微 。 感 谢 开 涛 为 大 家 带 来 这 本 互 
联网 高 并 发 架构 设计 的 百科 全 书 。 


李 尊 敬 京东 商城 交易 平台 架构 师 


作者 将 多 年 的 实践 经 验 和 人 研究 心得 呈现 在 这 本 书 中 ， 而 且 和 实践 很 好 地 
结合 起 来 ， 具 有 很 强 的 实践 指导 意义 。 从 各 个 角度 讲述 了 系统 设计 的 注 
意 点 与 优化 ， 一 层 一 层 从 前 到 后 ， 苑 围 广 而 详细 。 干 劲 十 足 ， 强 烈 推 


d 


赵 辉 ” 泵 东 商城 交易 平台 架构 师 
开 涛 理论 与 实践 经 验 结合 ， 循 序 渐进 地 将 构建 亿 级 流量 网 站 的 高 并 发 、 
高 可 用 的 一 系列 复杂 问题 阐述 得 很 清楚 。 阅 读 此 书 受益 菲 浅 ， 布 望 每 一 
位 开发 人 员 都 能 阅读 到 这 本 书 。 


尤 凤 凯 京东 商城 交易 平台 架构 师 


本 书 是 作者 在 未 东 商 品 详情 页 染 构 升级 实战 等 多 个 项 目 中 总 结 的 成 果 ， 
已 经 成 功 经 历 了 多 次 “618”`“ 双 11” 大 促 流 量 的 考验 ， 实 战 出 真理 ， 选 择 
这 本 书 ， 靠 庶 。 作 为 技术 进 阶 优选 的 书籍 ， 满 满 的 干货 ， 备 好 水 ， 慢 慢 
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刘 峻 桦 ” 京 东 商 城 网 站 平台 架构 师 
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开 涛 勤奋 好 学 又 乐于 分 娃 ， 他 很 早 束 深 读 了 不 少 开源 框架 源码 ， 吃 远 了 
内 核 技 术 ， 又 非常 喜欢 看 技术 大 侠 们 的 分 享 ， 不 断 与 同行 交流 ， 并 学 以 


致 用 ， 一 开始 参加 工作 就 站 在 了 较 高 的 起 点 上 ， 所 以 往往 比 同 龄 人 做 系 
统 更 加 有 信心 ， 成 采 更 加 突出 。 他 感恩 于 开源 和 分 享 ， 也 上 践 行 着 开源 分 
享 之 路 ， 每 次 埋头 探索 之 后 都 有 细心 总 结 ， 有 博客 时 写 博 客 ， 有 微 信 公 
众 号 时 发 公众 号 ， 把 学 到 的 和 在 实践 中 总 结 出 来 的 ， 都 无 私 分 享 出 来 。 


网 站 是 直接 面 对 广 大 客户 的 ， 是 公司 的 门户， 必须 快速 啊 应 ， 必 须 持续 
可 用 ， 必 须 抗 得 住 洪峰 。 任 何 一 个 网 站 的 发 展 过 程 中 都 出 现 过 问题 ， 影 
啊 客 户 体验 和 商业 利益 ， 公 司 业务 规模 武大 ， 网 站 出 现 问 题 的 损失 越 
大 。 作 者 进入 泵 东 后 ， 花 了 不 少 精力 从 事 了 “ 永 不 消失 的 网 站 ”建设 工 
作 。 作 者 和 同事 一 起 ， 克 服 了 一 个 义 一 个 难题 ， 将 口号 变 成 了 现实 。 


本 书 高 屋 建 叙 ， 抓 住 了 大 型 高 并 发 网 站 设计 的 核心 ， 从 设计 原则 ， 到 高 
性 能 、 高 吞吐 量 、 高 可 用 的 系统 设计 ， 到 高 灵敏 的 监控 系统 构思 、 再 到 
应 急 方案 的 制定 ， 不 失 细节 ， 又 不 拘泥 于 细节 。 相 比 其 他 已 出 版 的 关于 
大 型 网 站 的 架构 类 的 书籍 ， 此 书 更 加 贴近 实战 ， 追 求实 用 ， 所 有 内 容 来 
目 于 实战 ， 文 章 内 容 也 是 与 同道 和 网 友 们 互动 后 改进 的 ， 本 书 也 没有 那 
些 为 了 构建 一 个 “完整 的 体系 ”而 只 起 到 填充 作用 的 段落 。 此 书 特别 适合 
那些 快速 成 长 型 企业 网 站 的 建设 者 ， 互 联网 行业 的 研发 人 员 ， 对 较 大 规 
模 网 站 的 重 构 也 有 借鉴 意义 ， 看 这 本 书 可 以 少 走 些 这 路， 少 踩 些 坑 ， 其 
中 的 许多 党 略 和 技术 可 以 直接 拿 来 用 ， 从 而 节省 时 间 。 作 为 本 书 的 第 一 
批 读者 ， 发 现 这 本 书 的 内 容 组 织 上 兼 具 工具 书 的 特点 ， 没 有 严格 的 前 后 
依赖 ， 可 以 按 革 市 顺序 阅读 ， 也 可 以 随机 选取 中 间 的 一 革 。 文 中 公布 了 
作者 的 联络 方式 ， 有 问题 能 方便 地 交流 。 最 后 ， 硕 望 这 本 书 不 要 成 为 一 
个 网 站 以 构 分 画 的 终结 者 ， 和 希望 有 更 多 同学 加 入 到 探索 和 分 享 的 队伍 中 
来 ， 不 断 殉 服 新 的 挑战 ， 分 至 更 多 新 成 果 。 


京东 商城 副 总 裁 、 京 东 Y 事 业 部 负责 人 “于 永利 
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我 们 的 互联 网 开发 者 都 曾经 有 过 这 样 的 经 验 。 搭 建 一 个 设计 精 民 ， 功 能 
丰富 的 网 站 并 不 古 一 个 高 不 可 攀 的 事情 。 但 能 够 文 持 巨大 的 流量 而 运行 
自如 整 不 是 一 件 容易 的 事情 了 。 可 是 ， 当 你 拥有 《 亿 级 流量 网 站 架构 核 
心 技术 》 这 本 书 时 ， 这 一 切 勾 变 得 那么 轻松 。 


4《 亿 级 流量 网 站 架构 核心 技术 》 一 书 详细 地 阐述 了 开发 高 并 发 高 可 用 网 
站 的 一 系列 关键 原则 问题 。 束 如 何 实现 系统 高 可 用 ， 流 量 高 并 发 进行 了 
深刻 剖析 。 本 书 例 举 了 大 量 的 真实 应 用 案例 ， 帮 助 读者 深入 了 解 相关 知 
识 ， 并 且 使 得 枯燥 的 说 教 变 得 生动 ， 活 泌 。 


本 书 作 者 长 期 服务 于 泵 东 人 研发 的 第 一 线 ， 拥 有 丰富 的 软件 开发 经 答 。 柄 
持 着 对 技术 的 热爱 ， 为 互联 网 开发 者 奉献 目 己 的 心路 历程 。 希 望 他 的 读 
者 能 够 从 这 本 书 中 受益 。 


泉 东 集团 首席 技术 顾问 — $9585 
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经 历 过 “ 双 11” 和 “618” 的 同学 都 知道 ， 在 大 促 时 如 何 保证 系统 的 高 并 发 、 
高 可 用 是 非常 重要 的 事情 。 因 此 在 备战 大 促 时 ， 有 些 通用 原则 和 经 验 可 
以 帮助 我 们 在 遇 到 高 并 发 时 ， 构 建 更 可 用 的 系统 ， 如 限 流 、 降 级 、 水 平 
扩展 和 隔离 解 硝 等 。 通 过 这 些 原则 可 以 在 流量 超 预期 时 ， 很 好 地 保护 系 
统 ， 避 人 免 冲击 导致 的 系统 不 可 用 。 


以 前 系 东 也 过 到 过 一 些 高 可 用 问题 ， 如 超时 设置 不 合理 导致 系统 朋 涡 ; 
限 流 措施 不 到 位 ， 导 致 负载 过 高 时 系统 朋 涡 ， 解 灰 不 彻底 ， 导 致 某 个 服 
务 挂 掉 时 所 有 依赖 服务 受 影响 等 。 这 些 都 是 在 开发 和 运 维系 统 中 很 常见 
的 问题 ， 只 要 开发 人 员 在 开发 系统 时 注意 下 这 些 点 就 可 以 很 好 地 避免 。 
书 中 的 高 可 用 部 分 可 以 很 好 地 帮助 读者 解决 这 些 问题 。 


也 经 第 有 人 讨论 如 何 提升 系统 性 能 ， 最 直接 的 解决 方案 是 扩容 ， 或 通过 
如 加 缓存 来 提升 系统 并 发 能 力 ， 或 使 用 队列 进行 流量 前 峰 ， 也 可 以 使 用 
异步 并 发 机 制 提 升 吞 吐 量 或 者 接口 性 能 等 。 这 些 撤 术 老 生 篆 谈 ， 并 不 新 
鲜 ， 但 很 实用 ， 大 家 在 实现 高 并 发 系统 时 经 常会 遇 到 。 书 中 的 高 并 发 部 
分 可 以 帮助 读者 理解 和 使 用 这 些 技术 。 


这 本 书 还 有 一 部 分 介绍 实战 案例 ， 其 中 包含 了 汞 东 0 级 系统 “商品 详情 
页 ”和 “商品 详情 页 统一 服务 ”系统 ， 这 两 个 系统 每 天 承载 了 京东 几 十 亿 的 
流量 ， 书 中 深入 讲解 这 两 个 系统 的 核心 技术 ， 还 通过 案例 详细 介绍 如 何 
使 用 OpenResty 设 计 和 开发 高 性 能 web 应用， 值得 认真 阅读 。 


本 书 最 大 的 特点 是 实用 ， 书 中 的 原则 和 经 验 是 在 实战 中 总 结 和 进化 出 来 
的 。 市 面 上 系统 化 地 介绍 高 可 用 和 高 并 发 的 文章 并 不 多 ， 成 体系 的 号 更 
DT, RE ABE BOE TES Eo TERRIA, ARRA 
构 抽 象 能 力 、 扎 实 的 编程 基本 功 和 丰富 的 实战 经 验 ， 他 将 这 些 原 则 整理 
成 体系 ， 而 且 加 了 很 多 案例 ， 相 信 可 以 很 好 地 帮助 读者 学 习 和 使 用 这 些 
原则 ， 让 读者 读 完 此 书后 能 落地 到 实际 项 目 中 。 


ARRAS RÈ 
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大 型 互联 网 业务 需要 持续 建设 网 站 系统 并 通过 PC、 移动 等 各 种 终端 来 与 
用 户 进 行 交互 。 大 流量 网 站 架构 如 何 支 持 高 并 发 访问 并 且 保 证 高 可 用 
性 ， 这 是 一 个 持久 的 、 极 具 挑 战 的 技术 话题 。 毫 不 谷 张 地 说 ， 无 数 互联 
网 行业 的 工程 师 为 之 奋斗 。 


开 涛 是 系 东 优秀 技术 人 才 的 典型 代表 。 他 从 研发 一 线 做 起 ， 脚 踏实 地 成 
长 为 核心 架构 师 。 他 所 着 《 亿 级 流量 网 站 架构 核心 技术 》 一 书 ， 分 侍 高 
可 用 与 高 并 发 网 站 构建 技术 ， 干货 满 满 ， 特 点 鲜明 。 


第 一 ， 理 论 与 实践 结合 。 本 书 不 仅 总 结 出 一 系列 技术 方法 论 ， 而 且 配 合 
真实 的 案例 ， 九 妮 道 来 ， 深入浅出 。 读 者 可 以 直接 将 这 些 实用 技术 运用 
到 目 己 的 日 党 工作 中 。 


第 二 ， 深 度 与 广度 兼 具 。 本 书 选 题 极 具 针 对 性 ， 专 注 于 高 可 用 与 高 并 发 

两 方面 技术 实践 ， 每 个 方面 均 详 解 一 系列 技术 细节 。 

第 三 ， 技 术 与 业务 并 重 。 开 涛 并 没有 纯 谈 技术 ， 而 是 围绕 商品 详情 页 
泉 东 重要 的 业务 产品 之 一 ， 来 展开 更 进一步 的 实践 经 验 分 吝 ， 给 读 

者 从 业务 需求 到 技术 架构 的 完整 视图 。 


第 四 ， 新 兵 与 老将 咸 宜 。 无 论 是 第 一 年 人 事 软件 开发 的 工程 师 ， 还 是 工 
作 多 年 的 资深 人 士 ， 均 可 从 本 书 中 受益 。 


我 个 人 强烈 推荐 此 书 。 相 信 开 涛 的 作品 不 会 让 大 家 失望 。 
束 东 商城 总 架构 师 、 基 础 平台 负责 人 “刘海 锋 
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去 年 年 底 我 拿 到 本 书 的 电子 版 ， 受 邀 为 其 写 书评 。 全 书 篇 幅 很 长 ， 打 开 
修订 视图 后 ， 看 到 开 涛 在 即将 出 版 之 前 仍然 在 不 断 补 充 素 材 、 示 例 ， 推 
融 着 词句 。 在 读 到 其 中 的 某 个 部 分 的 时 候 ， 我 联想 到 当时 工作 中 正在 做 
的 一 个 优化 ， 还 跟 他 详细 讨论 过 ， 他 想 把 这 个 方案 也 补充 进去 作为 示 
例 。 我 说 ， 内 容 已 经 够 翔实 了 ， 还 嫌 书 不 够 厚 吗 ? 


征 的 ， 开 涛 恨不得 在 这 本 书 中 ， 一 股 脑 儿 地 告诉 大 家 他 所 在 领域 中 所 学 
到 和 实践 的 知识 。 写 书 是 一 个 吃力 还 不 一 定 能 讨好 的 活 儿 ， 很 佩服 他 居 
然 能 耐心 写 了 这 么 多 〈 还 有 很 多 限于 整 书 篇 幅 ， 链 接 到 他 的 博客 和 公众 
号 上 的 扩展 阅读 内 容 ) 。 我 看 到 了 作者 的 诚意 。 


全 书 前 半 部 分 我 是 利用 坐 地 铁 的 时 间 看 的 ， 昌 然 内 容 我 比较 熟悉 ， 但 想 
在 看 书 的 同时 如 有 果 能 提前 发 现 一 些 错误 就 更 好 了 ， 看 得 极 慢 。 不 过 ， 除 
了 一 些 笔 误 之 外 也 没 发 现 什 么 硬 伤 。 后 来 假期 拖延 钙 犯 了 ， 答 应 的 书评 
还 迟 迟 没有 写 完 ， 后 半 部 分 束 快 速 看 过 。 尤 其 是 第 4 部 分 案例 ， 差 不 多 束 
征 开 涛 目 己 之 前 的 工作 内 容 ， 这 些 或 多 或 少 地 都 通过 其 他 渠道 看 过 了 。 


开 涛 结合 自己 的 工作 内 容 ， 以 及 相关 上 下 游 依赖 系统 中 的 各 种 方案 、 架 
构思 想 ， 通 过 上 自己 的 思考 和 归 类 总 结 写成 本 书 。 其 中 不 仅 有 很 多 泵 东 的 
中 前 端的 架构 实践 和 技术 ， 还 有 作者 在 工作 过 程 中 用 到 的 很 多 技术 细 市 
甚至 代码 。 第 2、3 部 分 比较 详细 和 系统 地 说 明了 高 可 用 、 高 并 发 互联 网 
应 用 的 常用 架构 思想 和 设计 方法 ， 并 配合 不 同 的 场景 进行 举例 阐述 ， 比 
较 适 合 对 此 已 经 有 了 一 些 经 验 的 读者 。 针 对 一 些 常 见 软件 和 框架 的 细 广 
n 以 及 提供 很 多 代码 的 行文 风格 ， 也 许 能 满足 那些 想 立 即 动手 


架构 讲究 权衡 和 取舍 ， 但 是 前 提 之 一 是 尽 可 能 在 多 个 相关 领域 的 技术 知 
识 层面 有 经 验 ， 因 此 架构 也 很 重视 细节 ， 需 要 对 很 多 因素 有 充分 思考 和 
权衡 ， 才 有 取舍 。 读 者 在 阅读 本 书 的 过 程 中 ， 关 注 点 如 采 是 各 种 架构 方 
法 ， 则 需要 注意 作者 描述 的 适用 场景 。 如 采 关 注 点 是 各 种 具体 的 技术 细 
广 ， 也 不 要 起 记 思 考 背 后 所 体现 的 架构 思想 。 在 实际 的 工作 中 ， 很 多 方 
案 钙 否 干 架构 方法 和 技术 的 综合 运用 ， 并 且 随 着 业务 或 场景 的 变化 而 不 
断 调整 的 ， 不 要 拘泥 。 

突然 想到 了 《倚天 屠龙记 》 中 张无忌 癌 张 三 丰 学 太极 剑 一 丰 ， 最 后 张 无 
居 成 功 态 记 了 所 有 的 招式 。 对 于 武功 高 手 来 说 ， 最 后 都 是 要 融会 贯通 ， 
形成 目 身 体系 ， 不 要 被 特定 的 招式 所 束缚 。 学 习 以 构 ， 也 不 外 乎 是 吧 。 
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序 6 动 起 来 


开 涛 是 个 勤奋 的 写 手 ， 写 方案 ， 写 代码 ， 写 分 享 ， 和 孜孜 不 倦 。 对 于 大 多 
数 软件 开发 和 设计 人 员 来 说 ， 写 作 不 是 一 件 容 易 的 事 。 因 为 写 出 来 并 不 
征 给 上 自己 看 的 ， 和 是 要 给 同行 们 看 。 技 术 人 员 一 方面 对 好 的 技术 追求 大 


兆 ， 鸡 一 方面 又 天 然 地 用 批判 和 挑剔 的 眼光 看 同行 的 作品 ， 算 十 鲁 迅 先 
生 的 同道 吧 。 也 正 因为 如 此 ， 开 涛 为 此 书 内 容 的 质量 下 了 不 少 功夫 。 


开 涛 的 职业 生涯 从 空中 网 开始 ，2014 年 加 入 京东 ， 一 头 扎 进 了 超 0 级 系统 
的 建设 过 程 中 ， 束 东 商 城 商品 详情 页 改版 、 商 品 详情 页 统一 服务 规划 与 
落地 。 这 些 系统 代表 着 系 东 的 形象 ， 代 表 着 永 东 技术 团队 的 形象 OTF 
也 是 高 颜 值 ) 。 这 些 系统 必须 能 抗 峰值 、 不 掉 线 、 啊 应 快 ， 随 着 业务 量 
的 猛 增 ， 预 期 的 瓶颈 很 快 会 到 来 ， 这 次 关键 的 系统 改版 也 是 从 这 些 挑战 
FR, MREMA T KNARE mI, CWA TAER FR AA 


用 心 总 结 。 


作者 停 下 开发 的 脚步 ， 通 过 思考 和 总 结 ， 把 动态 的 实践 静止 到 了 纸张 
上 ， 给 大 家 市 来 了 精彩 ， 愿 各 位 读者 能 够 把 这 些 发 生 在 某 个 历史 瞬间 的 
实践 总 结 动态 地 运用 到 现实 的 开发 实践 中 。 也 期 望 作者 可 以 开放 群 或 者 
公众 号 ， 邀 请 技术 专家 进来 ， 与 读者 进行 交流 ， 动 起 来 。 
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序 7 开局 探索 之 旅 ， 感 受 技术 的 魅力 


近年 来 ， 中 国 的 互联 网 产业 正在 以 前 所 未 有 的 速度 迅猛 发 展 。 而 技术 在 
业务 发 展 中 所 扮演 的 角色 日 益 重 要 ， 随 着 各 个 业务 形态 的 发 展 涌现 出 了 
许多 技术 应 用 上 的 成 功 案例 和 先进 技术 的 研究 成 果 。 而 作者 在 本 书 中 则 
通过 对 工作 中 的 探索 和 总 结 来 将 系统 高 可 用 这 个 神秘 莫 测 的 面纱 揭 开 ， 
让 对 此 有 兴趣 的 人 得 以 蜂 其 真 容 。 


在 以 往 的 交流 和 面试 过 程 中 ， 大 多 数 的 研发 人 员 在 其 所 研发 的 系统 中 很 
少 有 机 会 或 确实 不 需要 和 繁多 的 上 下 游 系统 、 海 量 的 业务 数据 、 复 灯 的 
部 署 环 境 以 及 极端 灾难 《如 机 房 断 电 、 光 纤 损 坏 ) 打交道， 因此 也 没有 
契机 和 计划 去 详细 了 解 、 研 究 系 统 的 高 可 用 ， 对 于 系统 高 可 用 的 理解 和 
实践 大 多 集 留 在 理论 认 知 和 个 人 笑 试 阶段 ， 很 难 有 机 会 应 用 到 解决 实际 
业务 问题 上 ， 也 就 很 难 形成 目 己 技术 和 理念 上 的 一 个 积累 。 而 等 到 终于 
有 机 会 开始 在 海量 数据 和 高 并 发 场景 下 一 展 身 手 的 时 候 ， 又 稼 负 会 因为 
没有 系统 地 学 习 和 经 验 积 素 而 在 设计 系统 、 容 灾 策 略 、 解 决 问题 的 过 程 
中 艰难 前 行 。 本 书 则 通过 浅显 易 懂 的 理念 解读 和 实际 案例 将 系统 高 可 用 
相关 的 系统 设计 原则 、 系 统 限 流 、 降 级 措施 等 “兵法 三 十 六 计 ” 以 非常 直 
日 的 方式 持 现 给 了 大 家 。 让 我 们 对 于 一 些 冲 见 的 高 并 发 业务 场景 下 的 系 


统 设计 原则 、 高 可 用 策略 有 了 清晰 的 认识 和 思路 的 拓展 。 无 论 是 刚刚 接 
触 编 程 的 学 生 


还 是 已 身 经 百 战 的 一 线 研 发 人 员 都 可 以 从 书 中 得 到 很 多 启发 ， 也 许 只 是 
一 个 配置 的 改变 、 一 行 逻辑 的 优化 、 一 个 策略 的 调整 都 有 可 能 让 我 们 的 
系统 可 用 性 登 上 新 的 台阶 。 


系 东 的 网 站 系统 走 过 了 从 静态 到 动态 、 从 动态 到 动静 结合 、 从 对 DB 的 强 
依赖 到 多 级 缓存 、 从 重启 服务 器 到 自如 切换 流量 、 从 对 503 的 您 惯 到 从 容 
应 对 问题 、 从 修改 代码 应 对 异 第 到 修改 配置 轻松 搞定 的 系统 演变 历程 。 
当 一 个 系统 的 业务 体 量 达到 可 以 引起 系统 性 能 和 健壮 性 发 生 改变 的 时 
候 ， 伴 随 着 系统 问题 到 来 的 更 是 研发 人 员 上 自身 能 力 提 升 和 至 贯 经 验 积 款 
的 好 时 机 。 与 其 将 问题 用 重 局 应 用 和 “无 法 解释 的 诡异 问题 "来 掩盖 ， 不 
如 把 问题 的 根源 挖掘 出 来 。 如 有 果 控 掘 得 足够 深入 ， 一 切 问 题 都 是 可 解决 
的 。 书 中 使 用 的 技术 和 总 结 的 经 验 也 许 无 法 解决 书 中 业务 场景 之 外 的 问 
题 ， 但 这 也 恰恰 是 技术 的 魅力 所 在 。 没 有 一 种 技术 和 经 验 可 以 作为 系统 
的 万 能 解 药 来 帮助 我 们 一 劳 永 侈 地 避免 掉 所 有 隐患 ， 但 我 们 可 以 通过 对 
思想 的 接纳 和 消化 来 丰富 我 们 的 知识 体系 ， 让 我 们 成 为 一 个 有 思想 的 研 
发 人 员 。 阮 一 峰 曾 经 在 他 的 书 中 对 于 “如 何 变 有 思想 ”做 过 解释 ， 我 觉得 
非常 适合 用 在 研发 人 员 的 号 上 。 研 发 人 员 的 思想 是 什么 ? 当 你 对 一 个 需 
求 、 对 一 个 业务 形态 或 者 对 一 个 问题 有 目 己 的 观点 见解 ， 那 你 惑 是 有 思 
想 的 。 你 的 观点 越 多 束 越 可 能 接近 问题 的 本 质 ， 那 么 你 的 思想 惑 越 深 刻 
和 丰富 。 虽 然 你 的 观点 不 一 定 是 事实 也 不 一 定 是 正确 的 ， 但 作为 研发 人 
员 如 果 有 了 通过 不 断 探 索 、 质 疑 、 证 明 观 点 的 能 力 之 后 ， 那 么 也 就 有 了 
透析 问题 、 解 决 问题 的 能 力 。 那 么 在 面 对 一 个 看 似 简单 的 需求 或 者 业务 
时 ， 也 许 你 可 以 看 得 更 透彻 ， 将 系统 设计 得 更 适用 更 合理 ， 当 你 遇 到 书 
中 提 及 的 问题 时 也 可 以 开始 轻松 应 对 。 


我 想 ， 阅 读 并 了 解 书 中 对 于 系统 高 可 用 这 个 领域 的 介绍 一 定 会 让 你 乐 在 
其 中 。 虽 然 你 可 能 会 有 些 疑 惑 和 不 解 ， 但 作为 一 个 技术 人 对 于 技术 的 追 
求 和 探索 不 就 应 该 是 这 样 吗 ” 最 后 ， 我 邀请 你 一 起 踏 上 这 个 对 于 系统 高 
可 用 的 探索 之 旅 ， 来 感受 技术 的 魅力 。 
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序 8 


大 规模 分 布 式 系统 的 构建 ， 面 临 很 多 的 困难 和 问题 ， 但 是 请 记 住 ， 对 以 
构 师 而 言 ， 不 管 我 们 要 解决 多 少 困难 ， 最 重要 的 是 要 保证 系统 可 用 ， 无 


论 任何 环境 、 任 何 压 力 、 任 何 场景 ， 系 统 都 要 可 用 ， 这 有 征 我 们 的 第 一 要 
务 。 在 保证 系统 高 可 用 的 前 所 下 ， 大 型 分 布 式 系统 面临 的 最 突出 的 三 大 
问题 焉 是 : 如 何 应 对 高 并 发 、 如 何 处 理 大 数据 量 、 如 何 处 理 分 布 式 融 来 
的 一 系列 问题 。 这 也 是 很 多 一 线 架构 老司 机 们 的 感 恒 和 共识 。 


由 于 一 本 书 的 容量 有 限 ， 不 可 能 面面俱到 ， 因 此 本 书 集中 火力 ， 系 统 、 
详细 、 专业 地 讲述 了 : 大 型 分 布 式 系统 如 何 保证 高 可 用 性 ， 以 及 如 何 应 
对 高 并 发 这 两 个 大 方面 。 涉 及 很 多 技术 和 细 市 。 比 如 用 来 保证 高 可 用 
的 : 负载 均衡 和 反 向 代理 、 隔 离 、 限 流 、 降 级 、 超 时 与 重 试 等 ， 义 比如 
用 来 处 理 高 并 发 的 ， 应 用 缓存 、 多 极 缓存 、 连 接 池 、 异 步 并 发 、 队 列 处 
理 等 。 对 很 多 朋友 来 说 ， 这 里 面 很 多 知识 都 是 久 邮 其 名 ， 而 不 知 其 然 ， 

更 不 知 其 所 以 然 的 ， 学 习 本 书 正好 能 弥补 大 家 在 这 些 方面 的 知识 短 板 。 


作者 以 匠人 的 情怀 ， 把 每 个 方面 从 理论 到 应 用 、 从 技术 本 质 到 具体 实现 
都 讲 得 透彻 明了 ， 以 平实 而 不 失 激情 的 风格 妮 妮 道 来 ， 再 辅 以 实战 经 验 
的 扩展 ， 不 单单 让 读者 学 习 到 具体 的 技术 和 解决 问题 的 思路 ， 更 是 给 出 
neers 基本 上 可 以 把 这 些 方案 拿 到 实际 项 目 中 直 


尤为 难得 的 是 : 本 书 还 结合 实际 的 大 型 应 用 一 一 泵 东 的 商品 详情 页 的 实 
现 ， 详 细 讲 解 了 这 些 技术 和 方案 在 真实 场景 的 组 合 应 用 ， 以 更 好 地 让 知 
识 落 地 。 本 书 先 是 介绍 了 和 泵 东 商 品 详情 页 的 基本 功能 、 技 术 染 构 的 发 展 
以 及 架构 设计 ， 当 然 还 有 很 多 实际 的 经 验 和 体会 ， 以 “过 到 的 坑 和 问 
题 * 的 面 狐 出 现 ， 然 后 详细 地 讲述 了 泵 东 商品 详情 页 的 服务 闭环 实践 。 


为 了 更 好 地 讲述 京东 商品 详情 页 的 具体 实现 ， 作 者 先 讲述 了 实现 中 使 用 
的 基本 技术 OpenResty， 然 后 又 详细 地 讲解 如 何 使 用 OpenResty 来 开 
发 商品 详情 页 ， 里 面 涉及 好 多 具体 而 细 化 的 点 ， 都 是 实际 开发 中 会 用 到 
的 ， 值 得 去 认真 体会 。 这 样 真实 而 详细 地 讲述 这 种 大 型 系统 的 实现 ， 绝 
对 一 手 的 技术 资料 ， 是 具有 极 大 的 参考 价值 的 。 


其 实 ， 市 面 上 讲述 大 型 分 布 式 架构 的 书 很 多 ， 但 基本 上 都 停留 在 理论 和 
知识 的 层面 ， 看 上 去 都 很 对 ， 很 “高 大 上 ”， 但 就 是 落 不 了 地 ， 不 能 很 好 
地 跟 实 际 应 用 进行 结合 ， 从 而 导致 学 习 的 效果 人 欠 佳 。 而 本 书 很 好 地 解决 
了 这 个 问题 ， 不 仅 深入 浅 出 地 讲述 了 各 种 保障 高 可 用 ， 以 及 处 理 高 并 发 
的 技术 和 方案 ， 并 理论 联系 实际 ， 采 用 京东 商品 详情 页 的 具体 实现 这 个 
实际 案例 ， 来 综合 展示 了 这 些 技 术 的 应 用 ， 从 而 加 深 大 家 的 理解 和 领 
悟 ， 以 更 好 地 把 这 些 技术 和 方案 应 用 到 目 己 的 实际 项 目 中 去 。 


事实 上 ， 像 本 书 这 样 既 有 详尽 的 技术 学 习 ， 双 有 真实 、 典 型 案例 讲述 的 
好 书 ， 在 市 面 上 是 不 多 见 的， 毕竟 真正 拥有 这 种 大 型 系统 完整 腑 构 经 验 
的 人 并 不 多 ， 能 讲 明日 的 更 少 。 本 书 作者 恰好 就 是 那 极 少数 技术 、 经 验 
和 知识 传授 俱 佳 的 牛人 之 一 ， 这 是 读者 之 笠 。 仔 细 阅 读 完 本 书 ， 让 人 有 
一 种 醋 柄 灌顶 的 顿悟 ， 掩 卷 长 叹 “ 原 来 如 此 啊 ”。 


坦率 地 说 ， 本 书 不 是 写 给 初学 者 的 ， 对 于 有 一 定 的 开发 经 验 ， 甚 至 是 架 
构 设 计 经 验 的 朋友 ， 能 从 本 书 中 收获 更 多 。 但 我 仍然 确信 ， 不 管 是 富有 
经 验 的 架构 师 ， 还 是 想 要 学 习 染 构 知 识 的 入 门 者 ， 仔 细 、 深 入 阅读 本 
书 ， 就 一 定 会 有 收获 。 对 于 暂时 不 太 理 解 的 内 容 ， 建 议 反复 阅读 ， 或 者 
隅 段 时 间 再 看 ， 并 不 断 深 入 思考 ， 最 好 是 能 结合 实际 的 项 目 ， 把 这 些 知 
识 痢 应 用 上 去 ， 学 以 任用 ， 这 也 不 枉 费 作者 的 一 番 心 血 。 


细 想 起 来 ， 认 识 作 者 八 年 多 了 ， 有 眼看 着 作者 走出 校园 步 入 职场 ， 从 职场 
新 兵 ， 到 成 长 成 为 在 系 东 领导 着 上 百人 团队 的 技术 大 牛 ， 仿 佛 一 切 都 在 
上 昨天， 让 人 不 由 不 感慨 时 间 如 昌 骆 过 聊 。 在 我 眼中 ， 作 者 依然 是 那 帅 
气 、 阳 光 、 聪 明 而 又 略微 有 些 须 腊 的 大 男孩 形象 ， 喜 欢 研究 技术 ， 特 别 
好 学 、 善 思 、 勤 备 ， 且 积极 在 实际 工作 中 应 用 所 学 的 知识 ;喜欢 分 享 技 
术 ， 常 年 坚持 撰写 技术 博文 ， 拥 有 不 少 忠 实 粉 给， 在 泵 东 内 部 ， 也 是 特 
别 受 欢迎 的 讲师 之 一 。 另 外 告诉 大 家 一 个 小 秘密 ， 作 者 爱好 摄影 ， 绝 对 
专业 级 水 准 哦 。 


《人 研磨 设 计 模 式 》 作 者 ” 陈 蕊 
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为 什么 要 写 这 本 书 


在 2011 年 年 的 的 时 候 笔者 就 曾 规 划 写 一 本 Spring 的 书 ， 但 是 因为 是 Spring 
入 门类 型 的 书 ， 框 架 的 内 容 更 新 太 快 ， 觉 得 还 是 写 博客 好 一 些 ， 因 此 就 
E 5j si Hy -B dm « BR XX 9€ Spring 》 放 到 了 博客 
(jinnianshilongnian.iteye.com， 因 为 是 龙 年 开 的 博客 ， 很 多 网 友 喊 我 龙 年 
cL) 中 ， 并 持续 更 狐 ， 到 现在 已 经 差不多 五 年 了 。 大 家 在 网 上 找 资源 时 
会 发 现 ， 很 多 内 容 不 成 体系 ， 不 能 用 来 系统 地 学 习 ， 这 也 是 我 曾经 的 痛 
点 ， 因 此 我 写 博 客 的 一 个 特色 就 是 坚持 写 系列 文章 一 一 想 学 习 某 种 技术 
只 要 我 的 博客 有 就 不 需要 去 其 他 地 方 再 找 了 ， 到 现在 已 经 写 过 《 跟 我 学 
Spring》、《Spring 杂 谈 》、《 跟 我 学 Spring MVC》、《 跟 我 学 Shiro》、 
《 跟 我 学 Nginx+Lua》 等 系列 ， 累 计 访 问 量 已 超过 1000 万 。 我 写 博 客 还 有 
一 个 私心 : 带 新 人 ， 当 时 我 们 系统 架构 使 用 OpenResty， 而 团队 成 员 都 是 


Javakely it, PAMET 《 跟 我 学 OpenResty (Nginx*Lua) FFA) , IA 
跟着 教程 学 一 思 隋 能 上 手 干 活 了 。 扫 一 扫 关 注 我 的 博客 。 


2015 年 开始 ， 笔 者 在 个 人 公众 号 “ 开 涛 的 博客 ”撰写 《 聊 聊 高 并 发 系统 》 
系列 文章 ， 陆 续 发 表 了 《 聊 聊 高 并 发 系统 之 限 流 特技 》、《《 聊 聊 高 并 发 
系统 之 降级 特技 》、《 聊 聊 高 并 发 系统 之 队列 术 》、《 构 建 需 求 响应 式 
亿 级 商品 详情 页 》 等 文章 。 这 些 内 容 都 是 笔者 在 一 线 使 用 过 的 一 些 技 
能 ， 而 这 些 技能 又 是 一 线程 序 员 或 以 构 师 应 该 掌握 的 必 备 技能 。 而 且 这 
一 系列 也 得 到 了 很 多 读者 的 反馈 和 认可 ， 帮 助 他 们 解决 了 系统 的 一 些 问 
题 。 公 众 号 发 表 的 有 些 内 容 偏 理论 ， 很 多 人 不 知道 怎么 去 用 ， 因 此 束 有 
了 丰富 理论 和 实战 内 容 并 出 版 本 书 的 想法 。 想 学 习 高 可 用 和 高 并 发 系统 
技能 ， 看 这 本 书 束 够 了 ， 并 且 可 以 作为 案头 工具 书 来 用 。 


笔者 耗费 了 大 半年 业余 时 间 才 成 就 此 书 ， 
的 技术 可 以 帮助 到 读者 。 


本 书 讲解 的 原则 并 不 是 笔者 总 结 出 来 的 ， 有 许 许多 多 前 佛 们 已 经 实践 
过 ， 笔 者 只 是 花 了 点 时 间 进 行 汇总 ， 并 把 工作 中 使 用 过 的 一 些 经 验 和 案 
例 融 入 到 书 中 。 


成 长 和 进步 是 一 个 循序 渐进 的 过 程 ， 腺 图 看 完 本 书后 能 屠 龙 降魔 是 不 可 

能 的 ， 别 人 走 过 的 路 还 是 会 走 一 过 ， 别 人 踩 过 的 坑 还 古 会 踩 一 裔 。 正 如 

作家 格拉 德 威 尔 在 《异类 : 不 一 样 的 成 功 启示 录 》 一 书 中 的 一 万 小 时 害 

f. “人们 眼中 的 天 才 之 所 以 卓越 非 几 ， 并 非 天 资 超人 一 等 ， 而 是 付出 了 

m Nd ° 一 万 小 时 的 锤炼 是 任何 人 从 平 几 变 成 世界 级 大 师 的 必 
ZR ?» o 


读者 对 象 
本 书 布 望 对 在 一 线 从 事 开 发 工作 或 正在 解决 一 线 问 题 的 朋友 有 所 帮助 。 


望 这 些 实战 中 能 真 地 用 得 上 


a 


如 何 阅读 本 书 


本 书 的 内 容 是 理论 与 实战 相 结 合 ， 涉 及 的 知识 点 比较 多 ， 共 分 为 4 个 部 
分 ， 读者 可 按照 任何 顺序 阅读 每 一 个 部 分 ， 但 建议 先 阅读 第 1 部 分 进行 系 
统 了 解 。 


第 1 部 分 概述 ， 主 要 介绍 开发 高 并 发 系统 的 一 些 原 则 ， 并 阐述 本 书 将 要 讲 
解 的 原则 。 


第 2 部 分 高 可 用 ， 帮 助 读者 理解 高 可 用 的 一 些 原 则 ， 如 负载 均衡 、 限 流 、 
E. 、 超 时 与 重 试 、 回 深 机 制 、 压 测 与 预案 等 ， 并 能 实际 应 用 到 
AR NA 2 


第 3 部 分 高 并 发 ， 介 绍 开发 高 并 发 系统 的 一 些 原 则 ， 如 缓存 、 池 化 、 异 步 
化 、 扩 容 、 队 列 等 ， 并 配合 大 量 案例 帮助 读者 更 好 地 掌握 和 运用 。 


第 4 部 分 案例 ， 介 绍 笔者 开发 过 的 商品 详情 页 、 统 一 服务 等 系统 架构 ， 还 
有 一 些 静 态 化 架构 的 思路 ， 帮 助 读者 理解 前 边 介 绍 的 一 些 原则 。 


阅读 本 书 需要 对 Java、OpenResty (Nginx+Lua) 、Redis、MysQl 等 技术 

有 一 定 了 解 ，OpenResty 可 以 参考 我 的 博客 中 的 《 跟 我 学 OpenResty 
(NginxtLua) 开发 》 系 列 文章 。 本 文 提 到 的 Nginx+Lua 等同 于 

OpenResty。 可 扫 码 阅读 《 跟 我 学 OpenResty (Nginx+Lua) 开发 》。 


口 


因为 篇 幅 原 因 ， 本 书 示 例 很 难 做 到 全 面 且 详 细 ， 因 此 思路 不 要 受 限 于 书 
中 所 写 ， 要 活 学 活用 ， 举 一 反 三 。 比 如 多 级 缓存 的 思路 ， 可 以 扩展 到 多 
级 存储 WE -> NVMe/SATA SSD > HRÈ ° 


勘误 和 支持 


由 于 笔者 能 力 有 限 ， 虽 然 找 了 很 多 朋友 帮忙 校对 ， 但 书 中 难免 会 出 现 一 
些 错误 ， 也 请 读者 朋友 批评 指正 。 大 家 可 以 扫 如 下 二 二 维 码 关注 我 的 公众 
号 或 者 访问 我 的 博客 留言 反馈 错误 和 建议 ， 笔 者 会 积极 提供 解答 。 
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读者 服务 
轻松 注册 成 为 博文 视点 社区 用 户 (www.broadview.com.cn) ， 您 即 可 享受 


以 下 服务 : 


Ni 本 书 所 提供 的 示例 代码 及 资源 文件 均 可 在 【下 载 资源 】 处 下 


RMR: 您 对 书 中 内 容 的 修改 意见 可 在 【提交 勤 误 】 处 提交 ， 老 被 采 
纳 ， 将 获 赠 博文 视点 社区 积分 〈 在 您 购买 电子 书 时 ， 积 分 可 用 来 抵 扣 相 
应 金额 ) 


与 作者 交流 : 在 页 面 下 方 【 读 者 评论 】 处 留 下 您 的 疑问 或 观点 ， 与 作者 
和 其 他 读者 一 同学 习 交 流 。 


页 面 入 口 : http://www.broadview.com.cn/30954 
二 维 码 : 


2.8.1 Consul+Consul-template 


2.8.2  Consul*OpenResty 


4.4.1 ngx http limit conn module 


4.4.2. ngx http limit req module 


4.5.1  throttleFirst/throttleLast 


4.5.2 throttleWithTimeout 


6.2.2 Twemproxy 


9.6.3 Read-Through 


9.6.4 Wirite-Through 


Write-Behind 


15.9 Disruptor-Redis[A 7| 


3.8. Nginx-Luai? 7T Xx 
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高 并 发 原则 
高 可 用 原则 
-业务 设计 原则 
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,AN 一 口 


1 交易 型 系统 设计 的 一 些 原则 


在 我 们 的 技术 生涯 中 ， 总 是 不 断 针对 新 的 需求 去 研发 新 的 系统 ， 而 很 多 
系统 的 设计 都 是 可 以 触 类 旁 通 的 。 在 设计 系统 时 ， 要 因 场 景 、 时 间 而 
异 ， 一 个 系统 也 不 是 一 下 子 就 能 设计 得 非常 完美 ， 在 具有 有 限 资 源 的 情 
OLR, 一定 古 先 解决 当下 最 核心 的 问题 ， 预 测 并 发 现 未 来 可 能 出 现 的 问 
X, 一步 步 解 决 最 痛 点 的 问题 。 也 束 是 说 ， 系 统 设计 是 一 个 不 断 达 代 的 
过 程 ， 在 迭代 中 发 现 问题 并 修复 问题 ， 即 满足 需求 的 系统 是 不 断 欠 代 优 
化 出 来 的 ， 这 是 一 个 持续 的 过 程 ， 个 人 不 相信 完美 架构 银 弹 。 不 过 ， 如 
果 一 开始 就 有 好 的 基础 系统 设计 ， 未 来 可 以 更 容易 达到 一 个 比较 满意 的 
目标 。 一 个 好 的 设计 要 做 到 ， 解 决 现 有 需求 和 问题 ， 把 控 实 现 和 进度 风 
险 ， 预 测 和 规划 未 来 ， 不 要 过 度 设计 ， 从 迭代 中 演进 和 完善 。 


在 设计 系统 时 ， 应 该 多 思考 墨 菲 定律 。 

1. 任 何事 都 没有 表面 看 起 来 那么 简单 。 

2. 所 有 的 事 都 会 比 你 预计 的 时 间 长 。 

3. 可 能 出 错 的 事 总 会 出 错 。 

4. 如 果 你 担心 某 种 情况 发 生 ， 那 么 它 就 更 有 可 能 发 生 。 
在 系统 划分 时 ， 也 要 思考 康 威 定律 。 

1. 系 统 架构 是 公司 组 织 架 构 的 反映 。 


2. 应 该 按照 业务 闭环 进行 系统 拆 分 /组 织 架 构 划 分 ， 实 现 闭 环 /高 内 队 / 低 类 
合 ， 减 少 沟 通 成 本 。 


3. 如 采 沟 通 出 现 问 题 ， 那 么 就 应 该 考虑 进行 系统 和 组 织 染 构 的 调整 。 


4. 在 合适 时 机 进行 系统 拆 分 ， 不 要 一 开始 束 把 系统 /服务 拆 得 非常 细 ， 虽 
然 财 环 ， 但 是 每 个 人 维护 的 系统 多 ， 维 护 成 本 高 。 


应 该 多 发 励 团 队 成 员 积 极 主动 沟通 并 推动 系统 演进 。 另 外 ， 也 要 多 思考 
二 八 定 律 ， 在 系统 设计 初期 将 有 限 的 资源 用 到 刀刃 上 ， 以 最 小 化 可 行 产 
品 方式 迭代 推进 。 


在 持续 开发 系统 的 过 程 中 ， 会 有 一 些 设 计 原 则 /经 验 可 以 用 来 遵循 和 指导 
我 们 。 但 设计 原则 应 该 在 系统 迭代 过 程 中 ， 根 据 现 有 问题 或 特征 匹配 使 
用 ， 如 果 刚 开始 遇 到 的 不 是 核心 问题 ， 那 么 不 要 复杂 化 系统 设计 ， 但 移 
行规 划 和 设计 是 有 必要 的 ， 要 对 现 有 问题 有 方案 ， 对 未 来 娘 构 有 预案 。 


11 高 并 发 原则 


1.1.1 无 状态 


如 果 设 计 的 应 用 是 无 状态 的 ， 那 么 应 用 比较 容易 进行 水 平 扩展 。 实 际 生 
产 环境 可 能 是 这 样 的 : 应 用 无 状态 ， 配 置 文件 有 状态 。 比 如 ， 不 同 的 机 
房 需要 读 取 不 同 的 数据 源 ， 此 时 ， 束 需要 通过 配置 文件 或 配置 中 心 指 


Ps 


KE ? 


1.1.2 HI 


在 系统 设计 初期 ， 是 做 一 个 大 而 全 的 系统 还 是 按 功 能 模块 拆 分 系统 ， 这 
个 需要 根据 环境 进行 权衡 。 比 如 ， 做 私 享 在线 时 ， 本 映 用 户 量 /交易 量 不 
会 特别 大 ， 开 发 驶 笔者 一 个 人 人， 资源 有 限 ， 那 惑 没 必要 对 系统 拆 分 (E 
如 ， 拆 分 商品 、 订 单 等 ) ， 做 一 个 大 而 全 的 系统 即 可 。 而 像 设计 京东 秘 
杀 系 统 ， 访 问 量 是 非常 大 的 ， 而 且 投入 的 资源 还 是 蛮 充 足 的 ， 在 这 种 情 
况 下 ， 就 可 以 考虑 按 功 能 拆 分 系统 。 


笔者 遇 到 的 拆 分 主要 有 如 下 几 种 情况 。 


系统 维度 : 按照 系统 功能 /业务 拆 分 ， 比 如 商品 系统 、 购 物 车 、 结 算 、 订 
单 系统 等 。 


功能 维度 : 对 一 个 系统 进行 功能 再 拆 分 ， 比 如 ， 优 惠 券 系统 可 以 拆 分 为 
后 台 券 创建 系统 、 领 券 系 统 、 用 券 系 统 等 ; 


读 写 维度 ， 根 据 读 写 比 例 特征 进行 拆 分 。 比 如 ， 商 品系 统 ， 交 易 的 各 个 
系统 都 会 读 取 数据 ， 读 的 量 大 于 写 ， 因 此 可 以 拆 分 成 商品 写 服 务 、 商 品 
读 服务 ， 读 服务 可 以 考虑 使 用 绥 存 提升 性 能 ， 写 的 量 太 大 时 ， 需 要 考虑 
分 库 分 表 ; 有 些 聚 合 读 取 的 场景 ， 如 商品 详情 页 ， 可 考虑 数据 异 构 拆 分 
系统 ， 将 分 散在 多 处 的 数据 聚合 到 一 处 人 存储， 以 提升 系统 的 性 能 和 可 人 靠 


AOP 维 度 : 根据 访问 特征 ， 按 照 AOP 进 行 拆 分 ， 比 如 ， 商 品 详情 页 可 以 
分 为 CDN、 页 面 泻 染 系 统 ，CDN 就 是 一 个 AOP 系 统 。 


模块 维度 ， 比 如， 按照 基础 或 者 代码 维护 特征 进行 拆 分 ， 如 基础 模块 分 
库 分 表 、 数 据 库 连 接 池 等 ;代码 结构 一 般 按 照 三 层 架 构 (Web ` Service ` 
DAO) 进行 划分 。 


1.1.3 ”服务 化 


首先 ， 判 断 是 不 是 只 需要 简单 的 单 点 远程 服务 调用 ， 单 机 不 行 集群 是 不 
是 就 可 以 解决 ? 在 客户 端 注册 多 人 台 机 器 并 使 用 Nginx 进 行 负载 均衡 是 不 是 
WEA AER? 随 着 调用 方 越 来 越 多 ， 应 该 考虑 使 用 服务 自动 注册 和 发 现 
(如 Dubbo 使 用 ZooKeeper) 。 其 次 ， 还 要 考虑 服务 的 分 组 /隔离 ， 比 如 ， 
有 的 系统 访问 量 太 大 ， 导 人 致 把 整个 服务 打 挂 ， 因 此 ， 需 要 为 不 同 的 调用 
方 提 供 不 同 的 服务 分 组 ， 隔 离 访 问 。 后 期 随 着 调用 量 的 增加 还 要 考虑 服 
务 的 限 流 、 黑 白 名 单 等 。 还 有 一 些 细节 需要 注意 ， 如 超时 时 间 、 重 试 机 
制 、 服 务 路 由 〈 能 动态 切换 不 同 的 分 组 ) 、 故 障 补偿 等 ， 这 些 都 会 影响 
到 服务 的 质量 。 


总 结 为 : 进程 内 服务 ~ 单机 远程 服务 ~ 集群 手动 注册 服务 ~ 目 动 注册 和 
发 现 服务 -服务 的 分 组 /隔离 /路 由 一 服务 治理 如 限 流 / 黑 晶 名单。 


1.1.4 消息 队列 


消 思 队列 是 用 来 解 耦 一 些 不 需要 同步 调用 的 服务 或 者 订阅 一 些 上 自己 系统 
关心 的 变化 。 使 用 消 忌 队 列 可 以 实现 服务 解 厢 (一 对 多 消费 、 有 异步 处 
理 、 流 量 削 峰 / 缓 冲 等 。 比 如 ， 电 商 系统 中 的 交易 订单 数据 ， 该 数据 有 非 
党 多 的 系统 关心 并 订阅 ， 比 如 ， 订 单 生产 系统 、 定 期 送 系统 、 订 单 风 控 
系统 等 等 。 如 果 订 阅 者 太 多 ， 那 么 订阅 单个 消息 队列 束 会 成 为 浇 贷 ， 此 
时 ， 需 要 考虑 对 消息 队列 进行 多 个 镜像 复制 。 


使 用 消息 队列 时 ， 还 要 注意 处 理 生 产 消息 失败 ， 以 及 消息 重复 接收 时 的 
场景 。 有 些 消 筷 队列 产品 会 提供 生产 重 斌 功能， 在 达到 指定 重 试 次 数 还 
未 生产 成 功 时 ， 会 对 外 通知 生产 失败 。 这 时 ， 对 于 不 能 容忍 生产 失败 的 
业务 场景 来 说 ， 一 定 要 做 好 后 续 的 数据 处 理工 作 ， 如 持久 化 数据 要 同时 
增加 日 志 、 报 警 等 。 对 于 消息 重复 问题 ， 特 别 是 一 些 分 布 式 消 轧 队 列 ， 
出 于 对 性 能 和 开销 的 考虑 ， 在 一 些 场景 下 会 发 生 消息 重复 接收 ， 需 要 在 
业务 层面 进行 防 重 处 理 。 


1. 大 流量 缓冲 

在 电 商 搞 大 促 时 ， 系 统 流量 会 高 于 正常 流量 的 几 倍 甚至 几 十 倍 ， 此 时 就 
要 进行 一 些 特殊 的 设计 来 保证 系统 平稳 度 过 这 段 时 期 ， 而 解决 的 手段 很 
多 ， 一 般 都 是 牺牲 强 一 致 性 ， 而 保证 最 终 一 致 性 即 可 。 

比如 ， 扣 减 库存 ， 可 以 考虑 这 样 设 计 。 


E Redis 扣 减 库存 c» 记录 扣 减 日 志 


k 


3 


— 


同步 Worker — 库存 DB 


直接 在 Redis 中 扣 减 ， 然 后 记录 下 扣 减 日 志 ， 通 过 Worker 同 步 到 DB 。 
还 有 ， 如 交易 订单 系统 ， 可 以 考虑 这 样 设计 。 


3.1 
» 接 单 服务 7.1 
3.2 X 
REDE TIE: «- 同步 Worker mud 订单 中 心 表 | 


首先 ， 结 算 服务 调用 订单 接 单 服务 ， 将 订单 存储 到 订单 Redis 和 订单 队列 
表 ， 订 单 队 列表 可 以 按照 需求 水 平 扩 展 多 个 表 ， 通 过 队列 缓冲 表 提 升 接 
单 能 力 。 人 然后， 通过 同步 Worker 同 步 到 订单 中 心 表 ;假设 用 户 文 付 了 订 
单 ， 订 单 状态 机 会 驱动 状态 变更 ， 此 时 ， 可 能 订单 队列 表 的 订单 还 没有 
同步 到 订单 中 心 表 ， 状 态 机 要 根据 实际 情况 进行 重 试 。 


如 果 用 户 查 看 单个 订单 详情 ， 那 么 可 以 直接 从 订单 Redis 中 碍 到 。 但 如 果 
查询 订单 列表 ， 则 需要 考虑 订单 Redis 和 列表 的 合并 。 


同步 Worker 在 设计 时 ， 需 要 考虑 并 发 处 理 和 重复 处 理 的 问题 ， 比 如 ， 使 
用 单机 串 行 扫描 处 理 (每 台 Worker 只 扫描 其 中 的 一 部 分 表 ) 还 是 集群 处 
理 (Map-Reduce) 。 男 外 ， 和 需要 考虑 是 否 需 要 对 订单 队列 表 添 加 相关 字 
Bx: 处 理 人 (哪个 应 用 正在 处 理 ) 和 处 理 状态 (正在 处 理 、 已 处 理 、 处 
理 失 败 ) 、 最 后 处 理 时 间 (应 对 超时 ) 、 失 败 次 数 等 。 


2. 数 据 校 对 


在 使 用 了 消息 异步 机 制 的 场景 下 ， 可 能 存在 消息 的 丢失 ， 需 要 考虑 进行 
数据 校对 和 修正 来 保证 数据 的 一 致 性 和 完整 性 。 可 以 通过 Worker 定 期 去 
扫描 原始 表 ， 通 过 对 业务 数据 进行 校对 ， 有 问题 的 要 进行 补偿 ， 扫 描 周 
期 根据 实际 场景 进行 定义 。 


1.1.5 ”数据 异 构 
1. 数 据 异 构 


订单 分 库 分 表 一 般 按 照 订 单 ID 进行 分 ， 如 有 果 要 查询 某 个 用 户 的 订单 列 
表 ， 则 需要 聚合 多 个 表 的 数据 后 才能 返回 ， 这 样 会 导致 订单 表 的 读 性 能 
很 低 。 此 时 需要 对 订单 表 进 行 异 构 ， 异 构 一 套用 户 订单 表 ， 按 照 用 户 ID 
进行 分 库 分 表 。 另 外 ， 还 需要 考虑 对 历史 订单 数据 进行 归档 处 理 ， 以 提 
升 服务 的 性 能 和 稳定 性 。 而 有 些 数据 异 构 的 意义 不 大 ， 如 库存 价格 ， 可 
以 考虑 异步 加 载 ， 或 者 合并 并 发 请 求 。 


2. 数 据 闭环 
数据 闭环 如 商品 详情 页 ， 因 为 数据 来 源太 多 ， 影 响 服务 稳定 性 的 因素 束 


非常 多 了 。 因 此 ， 最 好 的 办 法 是 把 使 用 到 的 数据 进行 异 构 存储 ， 形 成 数 
据 财 环 ， 基 本 步 又 如 下 。 


` 数据 异 构 : 通过 如 MQ 机 制 接收 数据 变更 ， 然 后 原子 化 存储 到 合适 的 存 
储 引擎， 如 Redis 或 持久 化 KV 存 储 。 


BRS: 这 步 是 可 选 的 ， 数 据 异 构 的 目的 是 把 数据 从 多 个 数据 源 拿 过 
来 ， 数 据 聚 合 的 目的 是 把 这 些 数据 做 个 聚合 ， 这 样 前 端 殴 可 以 一 个 调用 
拿 到 所 有 数据 ， 此 步骤 一 般 存 储 到 KV 存 储 中 。 


前端 展示 : ”前 端 通过 一 次 或 少量 几 次 调用 拿 到 所 需要 的 数据 。 


这 种 方式 的 好 处 殉 是 数据 的 闭环 ， 任 何 依赖 系统 出 问题 了 ， 还 是 能 正常 
工作 ， 只 是 更 新 会 有 积压 ， 但 是 不 影 啊 前 端 展示 。 


另外 ， 此 处 如 果 一 次 需要 多 个 数据 ， 那 么 可 以 考虑 使 用 Hash Tag 机 制 将 相 
天 的 数据 聚合 到 一 个 实例 ， 如 在 展示 商品 详情 页 时 需要 商品 基本 信 
息 “p:productId:” 和 商品 规格 参数 “d:productId:”， 此 时 就 可 以 使 用 冒号 中 间 
为 数据 分 片 key， 这 样 相 同 productId 的 商品 相关 数据 就 在 一 
站 实例。 


数据 闭环 和 数据 异 构 其 实 是 一 个 概念 ， 目 的 都 是 实现 数据 的 目 我 控制 ， 


当 其 他 系统 出 问题 时 不 影响 自己 的 系统 ， 或 者 自己 出 问题 时 不 影响 其 他 
系统 。 一 般 通 过 消息 队列 来 实现 数据 分 发 。 


1.1.6 Jm 


缓存 对 于 读 服 务 来 说 可 谓 抗 流量 的 银 弹 ， 可 总 结 为 下 表 。 


流程 节点 缓存 技术 

使 用 浏览 器 缓存 

客户 端 
客户 端 应 用 缓存 

客户 端 网 络 代理 服务 器 开启 缓存 
使 用 代理 服务 器 ( 含 CDN) 

广域网 使 用 镜像 服务 器 
使 用 P2P 技术 


使 用 接 入 层 提 供 的 缓存 机 制 
使 用 应 用 层 提供 的 缓存 机 制 
源 站 及 源 站 网 络 使 用 分 布 式 缓存 


静态 化 、 伪 静态 化 
使 用 服务 器 操作 系统 提供 的 缓存 机 制 


本 表 由 林 世 洪 提供 。 


1. 浏 览 器 端 缓存 


设置 请 求 的 过 期 时 间 ， 如 对 响应 头 Expires、Cache-control 进 行 控 制 。 这 种 
机 制 适用 于 对 实时 性 不 太 敏感 的 数据 ， 如 商品 详情 页 框架 、 商 家 评分 、 
评价 、 广 告 词 等 ， 但 对 于 价格 、 库 存 等 实时 要 求 比较 高 的 数据 ， 惑 不 能 
(BLM DE aa DAE ° 


2.APP 客 户 端 缓存 


在 大 促 时 为 了 防止 瞬间 流量 冲击 ， 一 般 会 在 大 促 之 前 把 APP 需 要 访问 的 一 
些 素 材 (如 js/css/image 等 ) 提前 下 发 到 客户 端 进行 缓存 ， 这 样 在 大 促 时 
就 不 用 去 拉 取 这 些 素材 了 。 还 有 如 首 屏 数 据 也 可 以 缓存 起 来 ， 在 网 络 异 
" Lorem 托 底 数据 给 用 户 展示 ; 还 有 如 APP 地 图 一 般 也 会 做 地 图 的 
离线 缓存 。 


3.CDN 缓 存 


有 些 页 面 、 活 动 页 、 图 片 等 服务 可 以 考虑 将 页 面 、 活 动 页 、 图 片 推送 到 
离 用 户 最 近 的 CDN 节 点 ， 让 用 户 能 在 离 他 最 近 的 节点 找到 想 要 的 数据 。 
一 般 有 两 种 机 制 : 推送 机 制 ( 当 内 容 变更 后 主动 推送 到 CDN 边 缘 节 点 ) 
和 拉 取 机 制 ( 先 访问 边缘 节点 ， 当 没有 内 容 时 ， 回 源 到 源 服务 器 拿 到 内 
容 并 存储 到 市 点 上 ) ， 两 种 方式 各 有 利弊 。 使 用 CDN 时 要 考虑 URL 的 设 
计 ， 比 如 URL 中 不 能 有 随机 数 ， 否 则 每 次 都 罕 透 CDN 回 源 到 源 服务 器 ， 
aR o 对 于 谎 虫 ， 可 以 返回 过 期 数据 而 选择 不 回 
源 。 


4. 接 入 层 缓存 


对 于 没有 CDN 绥 存 的 应 用 来 说 ， 可 以 考虑 使 用 如 Nginx 搭 建 一 层 接 入 层 ， 
该 接 入 层 可 以 考虑 使 用 如 下 机 制 实现 。 


` URL 重 写 : 将 URL 按 照 指定 的 顺序 或 者 格式 重 写 ， 去 除 随机 数 。 


` 一致 性 哈 希 : 按照 指定 的 参数 (如 分 类 /商品 编号 ) 做 一 致 性 Hash， 从 
而 保证 相同 数据 落 到 一 台 服 务 器 上 。 


-proxy_cache: 使 用 内 存 级 /SSD 级 代理 缓存 来 缓存 内 容 。 


proxy cache lock: 使 用 lock 机 制 ， 将 多 个 回 源 合并 为 一 个 ， 以 减少 回 
源 量 ， 并 设置 相应 的 lock 超 时 时 间 。 


shared dict: 如 果 架 构 使 用 了 nginx+lua 实 现 ， 则 可 以 考虑 使 用 lua 
shared_dict 进 行 cache， 最 大 的 好 处 就 是 reload 绥 存 不 会 丢失 。 


此 处 要 注意 ， 对 于 托 克 (或 儿 克 ， 指 降级 后 显示 的 ) 数据 或 异 弟 数据 ， 
不 应 该 让 其 缓存 ， 否 则 用 户 会 在 很 长 一 段 时 间 里 看 到 这 些 数 据 。 


5. 应 用 层 缓存 


我 们 使 用 Tomcat 时 ， 可 以 使 用 堆 内 缓存 / 堆 外 缓存 ， 堆 内 缓存 的 最 大 问题 
就 是 重启 时 内 存 中 的 缓存 会 丢失 ， 此 时 流量 风 又 来临 ， 则 有 可 能 神 震 应 
用 ; 还 可 考虑 使 用 local redis cache 来 代替 堆 外 内 存 ; 或 在 接 入 层 使 用 
shared_dict 来 将 缓存 前 置 ， 以 减少 风暴 。 


local redis cache ， 通 过 在 应 用 所 在 服务 器 上 部 署 一 组 Redis， 应 用 直接 读 
本 机 Redis 获 取 数 据 ， 多 机 之 间 使 用 主 从 机 制 同步 数据 。 这 种 方式 没有 网 
络 消耗 ， 性 能 是 最 优 的 。 

6. 分 布 式 缓存 

有 一 种 机 制 是 要 废弃 分 布 式 缓存 ， 改 成 应 用 local redis cache 情 况 下 ， 如 果 
数据 量 不 大 ， 这 种 架构 是 最 优 的 。 但 是 如 果 数 据 量 太 大 ， 单 服务 器 存储 


^NI, 那么 可 以 使 用 分 请 机 制 将 流量 分 散 到 多 人 台 ， 或 者 直接 用 分 布 式 缓 
存 实现 。 篆 见 的 分 片 规则 就 是 一 致 性 哈 希 了 。 


Tomcat 


Redis 集 群 


Twemproxy 


RAL 


如 上 图 所 示 就 是 我 们 一 个 应 用 的 架构 。 

首先 接 入 层 (nginxtlua) 读 取 本 地 proxy cache / local cache ° 

` 如 果 不 命中 ， 则 接 入 层 会 接着 读 取 分 布 式 Redis 集 群 。 

如 果 还 不 命中 ， 则 会 回 源 到 Tomcat， 然 后 读 取 Tomcat 应 用 堆 内 cache 。 
E Om 则 调用 依赖 业务 来 获取 数据 ， 然 后 异步 化 写 到 Redis 
因为 我 们 使 用 了 nginx+lua， 第 二 、 三 步 时 可 使 用 lua-resty-lock 非 阻塞 锁 减 


少 峰 值 时 的 回 源 量 ;如 果 你 的 服务 是 用 户 维度 的 ， 那 么 这 种 非 阻 塞 锁 大 
部 分 情况 下 不 会 有 太 大 作用 〈 要 看 具体 场景 ) ° 


1.1.7 并 发 化 


假设 一 个 读 服 务 需要 如 下 数据 。 


目标 数据 
获取 时 间 


如 采 串 行 获取 ， 那 么 需要 60ms 。 


而 如 果 数 据 C 依 赖 数 据 A 和 数据 B、 数 据 D 谁 也 不 依赖 、 数 据 E 依 赖 数据 
C， 那 么 我 们 可 以 这 样 来 获取 数据 。 


数据 E 


10ms 


如 果 并 发 化 获取 ， 则 需要 30ms， 能 提升 一 倍 的 性 能 。 
假设 数据 E 还 依赖 数据 F (Sms) ， 而 数据 F 是 在 数据 E 服 务 中 获取 的 ， 此 


时 ， 就 可 以 考虑 在 此 服务 中 取 数 据 A/B/D 时 ， 预 取 数 据 F， 那 么 整体 性 能 
就 变 为 25ms。 


1.2 高 可 用 原则 


1.2.1 降级 


对 于 一 个 高 可 用 服务 ， 很 重要 的 一 个 设计 就 是 降级 开关 ， 在 设计 降级 开 
关 时 ， 主 要 依据 如 下 思路 。 


1. 开 关 集 中 化 管理 : 通过 推送 机 制 把 开关 推送 到 各 个 应 用 。 


推送 开关 配置 信息 


配置 中 心 系统 | 


订单 中 心服 务 订单 中 心服 务 订单 中 心服 务 


2. 可 降级 的 多 级 读 服务 : 比如 服务 调用 降级 为 只 读本 地 缓存 、 只 读 分 布 式 
缓存 、 只 读 默 认 降 级 数据 (如 库存 状态 默认 有 货 ) 。 


推送 开关 配置 信息 


配置 中 心 系统 | 


$ 
订单 中 心服 务 
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3. 开 关 前 置 化 : 如 架构 是 Nginx 一 Tomcat， 可 以 将 开关 前 置 到 Nginx 接 入 
a 在 Nginx 层 做 开关 ， 请 求 流量 回 源 后 端 应 用 或 者 只 是 一 小 部 分 流量 回 
源 。 


推送 开关 配置 信息 


OpenResty(nginx+lua) 


降级 后 不 回 源 Tomcat 集 群 ， 
或 者 只 有 一 小 部 分 流量 访问 


Tomcat 集 群 


4. 业 务 降 级 : 当 高 并 发 流量 来 委 ， 在 电 商 系统 大 促 设 计时 保障 用 户 能 

单 、 能 文 付 是 核心 要 求 ， 并 保障 数据 最 终 一 致 性 即 可 。 这 样式 可 以 把 一 
些 同步 调用 改 成 异步 调用 ， 优 先 人 处理 高 优先 级 数据 或 特殊 特征 的 数据 ， 
合理 分 配 进 入 系统 的 流量 ， 以 保障 系统 可 用 。 


1.2.2 BR 


限 流 的 目的 是 防止 恶意 请 求 流量 、 恶 意 攻 击 ， 或 者 防止 流量 超出 系统 峰 
值 。 可 以 考虑 如 下 思路 。 


1. 恶 意 请 求 流量 只 访问 到 cache。 

2. 对 于 穿 透 到 后 端 应 用 的 流量 可 以 考虑 使 用 Nginx 的 limit 模 块 处 理 。 

3. 对 于 恶意 IP 可 以 使 用 nginx deny 进 行 屏 蔽 。 

原则 是 限制 流量 穿 透 到 后 端 薄弱 的 应 用 层 。 
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对 于 一 个 大 型 应 用 ， 切 流量 是 非常 重要 的 ， 比 如 多 机 房 环境 下 某 个 机 房 
挂 了 ， 或 者 某 个 机 架 挂 了 ， 或 者 某 台 服务 器 挂 了 ， 都 需要 切 流 量 ， 可 以 
使 用 如 下 手段 进行 切换 。 

1.DNS: 切换 机 房 入 口 。 


2.HttpDNS: 主要 APP 场 景 下 ， 在 客户 端 分 配 好 流量 入 口 ， 绕 过 运营 商 
LocalDNS 并 实现 更 精准 流量 调度 。 


3.LVS/HaProxy: 切换 故障 的 Nginx 接 入 层 。 


4.Nginx: 切换 故障 的 应 用 层 。 


另外 ， 有 些 应 用 为 了 更 方便 切换 ， 还 可 以 在 Nginx 接 入 层 做 切换 ， 通 过 
Nginx 进 行 一 些 流 量 切换 ， 而 没有 通过 如 LVS/HaProxy 做 切换 。 


1.2.4 AJE 
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时 ， 如 果 有 版 本 化 机 制 ， 那 么 就 可 以 通过 回 深 恢 复 到 最 近 一 个 正确 的 版 
本 ， 比 如 事务 回 深 、 代 码 库 回 深 、 部 署 版 本 回 深 、 数 据 版 本 回 深 、 静 态 
资源 版 本 回 滚 等。 通过 回 深 机 制 可 保证 系统 某 些 场 景 下 的 高 可 用 。 


本 书 将 介绍 通过 负载 均衡 和 反 辐 代理 实现 分 流 ， 通 过 限 流 保护 服务 免 受 
雪 朋 之 灾 ， 通 过 降级 实现 部 分 可 用 、 有 损 服 务 ， 通 过 隔离 实现 故障 隔 
离 ， 通 过 设置 合理 的 超时 与 重 试 机 制 避 免 请 求 堆积 造成 雪 衣 ， 通 过 回 深 
2 快速 修复 错误 版 本 。 上 述 原则 用 来 保护 系统 ， 往 往 能 实现 系统 高 可 


1.3. 业务 设计 原则 


这 些 原则 本 书 只 进行 简单 介绍 ， 不 会 展开 讲解 ， 大 家 可 以 自行 研究 学 


1.3.1 Didi 


比如 ， 结 算 页 需要 考虑 重复 提交 ， 还 有 如 下 单 扣 减 库存 时 需要 防止 重复 
扣 减 库存 。 解 决 方案 可 以 考虑 防 重 key、 防 重 表 。 而 有 些 场景 如 重复 支 
付 ， 有 是 因为 有 的 电 商 网 站 同时 文 持 微 信 文 付 、 京 和 东 文 付 ， 渠 道 不 一 样 是 
无 法 防止 重复 文 付 的 。 但 是 ， 在 系统 设计 时 ， 需 要 将 文 付 的 每 笔 情 况 记 
录 下 来 。 下 图 是 笔者 在 京东 使 用 京东 支付 和 微 信 支 付 模拟 的 重复 支付 之 
后 进行 退 款 的 文 付 明细 。 


HHS: ¥125.60 
支付 明细 WTR: ¥62.80 
RATE: Y62.80 


1.3.2 $E 


在 交易 系统 中 ， 经 常会 用 到 消息 ， 而 现 有 消息 中 间 件 基本 不 保证 不 发 生 
重复 消息 的 消费 。 因 此 ， 需 要 业务 系统 在 重复 消息 消费 时 进行 项 等 处 
理 。 还 有 在 使 用 第 三 方 文 付 时 ， 第 三 方 文 付 会 进行 异步 回调 ， 也 要 考虑 
做 好 回调 的 需 等 处 理 。 


1.3.3 ”流程 可 定义 


如 果 接 触 过 保险 业务 ， 就 会 发 现 不 同 保险 的 理赔 服务 是 不 一 样 的 。 我 们 
在 系统 设计 时 就 设计 了 一 套 理赔 流程 服务 。 而 承保 流程 和 理赔 流程 是 分 
网 人 从 而 可 以 复 用 一 些 理赔 流程 ， 并 提供 个 性 化 
J 理赔 流程 。 


1.3.4 ”状态 与 状态 机 


在 设计 交易 订单 系统 时 ， 会 存在 正 向 状态 〈 待 付款 、 待 发 货 、 已 发 货 、 
完成 ) 和 逆向 状态 〈 取 消 、 退 款 ) 等 ， 正 向 状态 和 送 癌 状态 应 该 根据 系 
统 的 特征 来 决定 要 不 要 分 离 存 储 。 状 态 设 计时 应 有 状态 轨迹 ， 方 便 用 户 
跟踪 当前 订单 的 轨迹 并 记录 相关 日 志 ， 万 一 出 问题 时 可 回调 问题 。 


男 外 ， 还 有 订单 状态 的 变迁 ， 比 如 竺 支付 、 已 支付 等 发 贷 、 答 收 贷 、 完 
成 的 迁移 。 要 考虑 要 不 要 使 用 状态 机 来 驱动 状态 的 变更 和 后 续 流 程 节 点 
操作 ， 无 其 当 状 态 很 多 的 时 候 使 用 状态 机 能 更 好 地 控制 状态 迁移 。 


还 要 考虑 并 发 状态 修改 问题 ， 如 一 个 订单 同时 只 能 有 一 个 修改 ;状态 变 
更 的 有 序 问 题 ， 以 及 状态 变更 消息 的 移 到 后 到 问题 ， 如 支付 成 功 消 轧 和 
用 户 取 消 消 息 的 时 间 差 。 


13.5 后台 系统 操作 可 反馈 

在 笔者 接触 过 的 系统 中 ， 很 多 场景 都 需要 反馈 ， 比 如 ， 修 改 了 某 些 内 容 
后 想 预 览 看 看 最 终 效果 ， 即 想得到 一 些 反馈 ， 还 有 一 些 是 在 规则 系统 
中 ， 和 希望 看 到 这 些 规则 在 系统 数据 下 的 反馈 。 困 此 ， 在 设计 后 台 系统 
时 ， 需 考虑 效果 的 可 预览 、 可 反馈 。 

13.6 ”后 人 台 系 统 审批 化 


对 于 有 些 重 要 的 后 台 功 能 需要 设计 审批 流 ， 比 如 调整 价格 ， 并 对 操作 进 
行 日 志 记 录 ， 从 而 保证 操作 可 追溯 、 可 审计 。 


1.3.7 文档 和 注释 


笔者 接触 的 一 些 系 统 是 完全 没有 文档 、 代 码 没 有 注释 的 ， 完 全 是 人 传 
人 。 这 将 导致 后 来 人 接手 很 痛苦 ， 而 且 对 有 些 代码 是 完全 不 敢 改 动 的 ， 
比如 ， 有 些 代 码 完全 是 因为 业务 的 一 些 特殊 情况 而 写 的 ， 可 以 说 没有 注 
释 是 完全 不 懂 为 什么 那么 做 的 。 因 此 ， 在 一 个 系统 发 展 的 一 开始 就 应 该 
有 文档 库 (设计 染 构 、 设 计 思 想 、 数 据 字典 /业务 流程 、 现 有 问题 ， 业 
务 代 码 和 特殊 需求 都 要 有 注释 。 


1.3.8 备份 


包括 代码 和 和 人员。 代码 主要 提交 到 代码 仓库 进行 管理 和 备份 ， 代 码 仓 库 
应 该 至 少 具 备 多 版 本 的 功能 。 人 员 备 份 指 的 是 一 个 系统 至 少 应 该 有 两 名 
开发 人 员 是 了 解 的 ， 即 使 其 中 一 名 离职 了 也 不 会 出 现 新 人 接手 之 后 手 忙 
脚 乱 事故 频 发 的 状况 。 还 有 一 些 是 “核心 人 员 ”， 写 着 系统 的 核心 代码 ， 
被 认为 是 “不 可 符 代 的 ”>， 这 种 情况 也 是 尽 可 能 地 让 他 市 一 名 兄弟 一 起 开 
发 核心 代码 (业务 系统 ， 即 使 离职 也 还 是 可 以 努力 一 下 克服 困难 。 


1.4 Hi 


JAZA 


对 于 一 个 系统 设计 来 说， 不 仅 需要 考虑 实现 业务 功能 ， 还 要 保证 系统 高 
并 发 、 高 可 用 、 高 可 靠 等 。 在 系统 容量 规划 (DEC ABS) ^ SLATE 
E 《吞吐 量 、 响 应 时 间 、 可 用 性 、 降 级 方案 等 ) 、 压 测 方案 (AEE > 
ES) 、 监 控 报警 〈《 机 器 负载 、 响 应 时 间 、 可 用 率 等 ) > WAI (A 
灾 、 降 级 、 限 流 、 隔 离 、 切 流量 、 可 回 深 等 ) 等 方面 ， 也 要 有 一 些 原 则 
来 指导 大 家 。 其 中 ， 每 一 个 方向 都 是 很 复杂 的 ， 为 了 能 讲解 地 较为 深 
入 ， 本 书 将 从 高 并 发 和 高 可 用 两 个 方面 来 讲解 ， 并 配合 案例 实战 使 读者 
能 参考 案例 ， 来 理解 这 些 原 则 并 解决 系统 痛 点 。 


本 书 将 介绍 缓存 、 异 步 并 发 、 连 接 池 、 线 程 池 、 如 何 扩容 、 消 息 队 列 、 
分 布 式 任务 等 高 并 发 原则 来 提升 系统 否 吐 量 。 


本 书 将 介绍 通过 负载 均衡 和 反 辐 代理 实现 分 流 ， 通 过 限 流 保护 服务 免 受 
雪 朋 之 灾 ， 通 过 降级 实现 部 分 可 用 、 有 损 服 务 ， 通 过 隔离 实现 故障 隔 
离 ， 通 过 设置 合理 的 超时 与 重 试 机 制 避免 请 求 堆积 造 成 雪 衣 ， 通 过 回 深 
机 制 快 速 修复 错误 版 本 ;通过 上 述 原则 来 保护 系统 ， 使 得 系统 高 可 用 。 
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ERR : 压 测 接口 /并 发 量 / 压 测 策略 / 压 测 指标 
载 /QPS/ 响 应 时 间 / 成 功率 


单机 /集群 /离散 /全 链 路 压 测 


应 急 预案 
网 络 接 入 层 ( DNS/LVS/HaProxy ) 
应 用 接 入 层 (Nginx/OpenResty) 
WEB 应 用 层 ( Tomcat ) 
服务 层 ( Dubbo ) 
数据 层 ( Redis/DB ) 


监控 报警 
服务 器 监控 /系统 监控 /VM 监 控 / 接 口 监控 
报警 策略 : 监控 时 间 段 、 报 警 闪 值 、 通 知 方式 


缓存 回收 策略 : 空间 /容量 /时 间 


缓存 回收 算法 
FIFO/LRU/LFU 


Java 堆 /Java 扒 外 /磁盘 缓存 
Guava/Ehcache/MapDB 


缓存 使 用 模式 
Cache-Aside/Cache-As-SoR/Copy 
Pattern 
浏览 器 缓存 
HttpClient 客 户 端 缓存 
Nginx 代 理 层 缓存 


分 布 式 缓存 
热点 数据 与 更 新 缓存 


一 | HTTP 缓 存 


| 异步 并 发 
| 。 应 用 级 缓存 


更 新 缓存 与 原子 性 | | 多 级 缓存 


缓存 崩溃 与 快速 修复 


数据 库 连 接 池 
HttpClient 连 接 池 
线程 池 


队列 


第 2 部 分 高 可 用 


- 负载 均衡 与 反 疝 代理 
` 隔离 术 

- 限 流 详解 

` 降级 特技 

超时 与 重 试 机 制 

- 回 深 机 制 

` 压 测 与 预案 


同步 阻塞 调用 

异步 Future 

异步 Callback 

异步 编排 CompletableFuture 
请 求 缓存 

请 求 合并 


单 体 应 用 垂直 扩容 

单 体 应 用 水 平 扩容 
应 用 拆 分 

数据 库 拆 分 :水 平 /垂直 拆 分 


使 用 sharding-jdbc 
分 库 分 表 / 读 写 分 离 


数据 异 构 

任务 系统 扩容 ( Elastic-Job ) 
异步 处 理 / 系 统 解 硬 
数据 同步 /流量 削 峰 


缓冲 队列 /任务 队列 /消息 队列 
请 求 队列 /数据 总 线 队 列 


Disruptor+ Redis 队 列 
基于 Canal 实 现 数据 异 构 


2 负载 均衡 与 反 回 代理 


当 我 们 的 应 用 单 实 例 不 能 文 撑 用 户 请 求 时 ， 此 时 就 需要 扩容 ， 从 一 台 服 
务 器 扩容 到 两 台 、 几 十 台 、 几 百 台 。 然 而 ， 用 户 访 问 时 是 通过 如 
http://www.jd.com 的 方式 访问 ， 在 请 求 时 ， 浏 贤 絮 首先 会 查询 DNS 服 务 恬 
获取 对 应 的 IP， 然 后 通过 此 IP 访 问 对 应 的 服务 。 


因此 ， 一 种 方式 是 www.jd.com 域 名 映射 多 个 IP， 但 十， 存在 一 个 最 简单 
的 问题 ， 假 设 某 侣 服务 器 重 局 或 者 出 现 故 障 ，DNS 会 有 一 定 的 缓存 时 
T c POP US 而 且 没 有 对 后 端 服务 进行 心跳 检查 和 失败 重 试 
N lo 


因此 ， 外 网 DNS 应 该 用 来 实现 用 GSLB (全 局 负载 均衡 ; 进行 流量 调度 ， 

如 将 用 户 分 配 到 离 他 最 近 的 服务 器 上 以 提升 体验 。 而 且 当 某 一 区 域 的 机 

e (如 被 控 断 了 光 绕 ) ， 可 以 通过 DNS 指 疝 其 他 区 域 的 IP 来 
务 可 用 。 


可 以 在 站 长 之 家 使 用 “DNS 碍 询 ”， 查询 c.3.cn 可 以 看 到 类 似 如 下 的 结 


京 [电信 106.39.164.153 [北京 市 北京 电信 互联 网 数据 中 心 8 
上 海 [ 电 信 106.39.164.153 [北京 市 北京 电信 互联 网 数据 中 心 ] 116 
Ae [EE 111.13.28.153 [北京 市 移动 ] 19 
Fz 

湖北 [移动 106.39.164.153 [北京 市 北京 电信 互联 网 数据 中 心 ] 600 


即 不 同 的 运营 商 返 回 的 公 网 JP 是 不 一 样 的 。 


对 于 内 网 DNS， 可 以 实现 简单 的 轮 询 负载 均衡 。 但 是 ， 还 是 那 句 话 ， 会 
有 一 定 的 缓存 时 间 并 且 没 有 失败 重 试 机 制 。 因 此 ， 我 们 可 以 考虑 选择 如 
HaProxy 和 Nginx ° 


而 对 于 一 般 应 用 来 说 ， 有 Nginx 就 可 以 了 。 但 Nginx 一 般 用 于 七 层 负载 均 
衡 ， 其 吞吐 量 是 有 一 定 限 制 的 。 为 了 提升 整体 吞吐 量 ， 会 在 DNS 和 Nginx 
之 间 引 入 接 入 层 ， 如 使 用 LVS (软件 负载 均衡 器 、F5 〈 硬 负载 均衡 器 ) 
可 以 做 四 层 负载 均衡 ， 即 首先 DNS 解析 到 LVSMF5， 然 后 LVS/F5 转 发 给 
Nginx， 再 由 Nginx 转 发 给 后 端 Real Server ° 


S m, www.jd.com——3J9»* 
DUE DNS 
«———2. 106.39.178.1 


3. 106.39.178.1 


LVS/F5 


Nginx 


Nginx 


| Tomcat | Tomcat Tomcat 


对 于 一 般 业 务 开 发 人 员 来 说 ， 我 们 只 需要 关心 到 Nginx 层 面 就 够 了 ， 
LVS/F5 一 般 由 系统 / 运 维 工程 师 来 维护 。Nginx 目 前 提供 了 HTTP 

(ngx http upstream module) 七 层 负载 均衡 ， 而 1.9.0 版 本 也 开始 文 持 
TCP (ngx stream, upstream module) 四 层 负载 均衡 。 


此 处 再 澄 请 儿 个 概念 。 二 层 负载 均衡 是 通过 改写 报 文 的 目标 MAC 地 址 为 
上 游 服 务 絮 MAC 地 址 ， 源 IP 地 址 和 目标 IP 地 址 是 没有 变 的 ， 负 载 均 衡 服 
务 器 和 真实 服务 器 共享 同一 个 VIP， 如 LVS DR 工作 模式 。 四 层 负 载 均衡 
是 根据 端口 将 报 文 转发 到 上 游 服 务 器 〈 不 同 的 耳 地 址 + 端口 ) ， 如 LVS 
NAI 模 式 、HapProxy， 七 层 负载 均衡 是 根据 端口 号 和 应 用 层 协议 如 HTTP 
协议 的 主机 名 、URL， 转 发 报 文 到 上 游 服务 器 〈 不 同 的 卫 地 址 + 端口 ) ， 
"liIHaProxy ^ Nginx ° 


这 里 再 介绍 一 下 LVS DR 工作 模式 ， 其 工作 在 数据 链 路 层 ，LVS 和 上 游 服 
务 器 共 至 同一 个 VIP， 通 过 改写 报 文 的 目标 MAC 地 址 为 上 游 服 务 嚣 MAC 
地 址 实现 负载 均衡 ， 上 游 服务 器 直接 响应 报 文 到 客户 并 ， 不 经 过 LVS， 从 
而 提升 性 能 。 但 因为 LVS 和 上 游 服务 器 必须 在 同一 个 子 网 ， 为 了 解决 跨 子 
网 问题 而 又 不 影响 负载 性 能 ， 可 以 选择 在 LVS 后 边 挂 HaProxy， 通 过 四 到 
七 层 负载 均衡 器 HaProxy 集 群 来 解决 跨 网 和 性 能 问题 。 这 两 个 “半成品 ?的 
东西 相互 取长补短 ， 组 合 起 来 束 变 成 了 一 个 “完整 ”的 负载 均衡 右 。 现 在 
Nginx 的 stream 也 文 持 TCP， 所 以 Nginx 也 算是 一 个 四 到 七 层 的 负载 均衡 
器 ， 一 般 场 景 下 可 以 用 Nginx 取 代 HapProxy。 


在 继续 讲解 之 前 ， 首 先 统一 几 个 术语 。 接 入 层 、 反 向 代理 服务 器 、 负 载 
均衡 服务 器 ， 在 本 文中 如 无 特殊 说 明 则 指 的 是 Nginx。upstream server 即 上 
游 服 务 器 ， 指 Nginx 负 载 均衡 到 的 处 理 业 务 的 服务 器 ， 也 可 以 称 之 为 real 
server， 即 真实 处 理 业务 的 服务 器 。 


对 于 负载 均衡 我 们 要 关心 的 几 个 方面 如 下 。 
上 游 服 务 器 配置 : 使 用 upstream server 配 置 上 游 服务 器 。 
负载 均衡 算法 : 配置 多 个 上 游 服务 器 时 的 负载 均衡 机 制 。 


失败 重 斌 机制， 配置 当 超时 或 上 游 服务 器 不 存活 时 ， 是 否 需 要 重 试 其 他 
EUR AS ae ° 


服务 器 心跳 检查 : 上游 服务 器 的 健康 检查 /心跳 检查 。 


Nginx 提 供 的 负载 均衡 可 以 实现 上 游 服 务 器 的 负载 均衡 、 故 障 转 移 、 失 败 
重 试 、 容 错 、 健 康 检 查 等 ， 当 某 些 上 游 服 务 右 出 现 问 题 时 可 以 将 请 求 转 
到 其 他 上 游 服务 邵 以 保障 高 可 用 ， 并 可 以 通过 OpenResty 实 现 更 智能 的 负 
载 均衡 ， 如 将 热点 与 非 热 点 流量 分 离 、 正 背 流 量 与 朴 虫 流量 分 离 等 。 
Nginx 人 负载 均衡 器 本 身 也 是 一 台 反 向 代理 服务 器 ， 将 用 户 请 求 通过 Nginx 
代理 到 内 网 中 的 某 台 上 游 服务 器 处 理 ， 反 向 代理 服务 器 可 以 对 响应 结果 
进行 缓存 、 压 缩 等 处 理 以 提升 性 能 。Nginx 作 为 负载 均衡 右 / 反 向 代理 服务 
如 如 下 图 所 示 。 
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Upstream Server 


We HTTP 负 载 均 衡 ， 最 后 会 讲解 使 用 Nginx 实 现 四 层 负 
> EJ o 


2.1 upstream & 


第 一 步 我 们 需要 给 Nginx 配 置 上游 服 务 器 ， 即 负载 均衡 到 的 真实 处 理 业 务 
的 服务 右 ， 通 过 在 http 指 令 下 配置 upstream 即 可 。 


upstream backend { 
server 192.168.61.1:9080 weight-1; 
server 192.168.61.1:9090 weight-; 
} 


upstream server 的 主要 配置 如 下 。 

IP 地 址 和 端口 : 配置 上 游 服务 器 的 IP 地 址 和 端口 。 

` 权重 : weight 用 来 配置 权重 ， 默 认 都 是 1， 权 重 越 高 分 配给 这 台 服 务 器 
的 请 求 束 越 多 (如 上 配置 为 每 三 次 请 求 中 一 个 请 求 转发 给 9080， 其 余 两 
个 请 求 转发 给 9090) ， 需 要 根据 服务 器 的 实际 处 理 能 力 设置 权重 ( 比 
如 ， 物 理 服务 器 和 虚拟 机 就 需要 不 同 的 权重 ) 。 


然后 ， 我 们 可 以 配置 如 下 proxy_pass 来 处 理 用 户 请 求 。 


location / ( 
proxy pass http://backend; 
} 


当 访 问 Nginx 时 ， 会 将 请 求 反 辐 代 理 到 backend 配 置 的 upstream server。 接 
下 来 我 们 看 一 下 负载 均衡 算法 。 


A A Y 
2.2 ”负载 均衡 算法 
负载 均衡 用 来 解决 用 户 请 求 到 来 时 如 何 选 择 upstream server 进 行 处 理 ， 默 
认 采 用 的 是 round-robin ($818) ， 同 时 文 持 其 他 几 种 算法 。 


-round-robin: 轮 询 ， 默 认 负 载 均衡 算法 ， 即 以 轮 询 的 方式 将 请 求 转发 
到 上 游 服 务 器 ， 通 过 配合 weight 配 置 可 以 实现 基于 权重 的 轮 询 。 


ip hash: 根据 客户 IP 进 行人 负载 均衡 ， 即 相同 的 IP 将 负载 均衡 到 同一 


upstream server ° 


upstream backend { 
ip hash; 
server 192.168.61.1:9080 weight=1; 
server 192.168.61.1:9090 weight=2; 


. hash key [consistent]: ”对 某 一 个 key 进 行 哈 希 或 者 使 用 一 致 性 哈 希 算法 
re si ea he ， 当 添加 /删除 一 台 服 务 器 
时 ， 将 导致 很 多 key 被 重新 负载 均衡 到 不 同 的 服务 器 〈 从 而 导致 后 端 可 能 
出 现 问 题 ) ; 因此 ， 建 议 考 虚 使 用 一 致 性 哈 希 算法 ， 这 样 当 添加 /删除 一 
台 服 务 絮 了 时， 只 有 少数 key 将 被 重 狐 负 载 均 衡 到 不 同 的 服务 器 。 


E 
哈 希 算法 : 此 处 是 根据 请 求 ui 进行 负载 均衡 ， 可 以 使 用 Nginx 变 
量 ， 因 此 ， 可 以 实现 复杂 的 算法 。 


upstream backend { 
hash Suri; 
server 192.168.61.1:9080 weight=1; 
server 192.168.61.1:9090 weight=2; 


一 致 性 哈 希 算法 : consistent_key ATE 


upstream nginx local server { 
hash $consistent key consistent 
server 192.168.61.1:9080 weight=1; 
server 192.168.61.1:9090 weight-2; 


} 
合 希 key， 此 处 会 优先 考虑 请 求 参数 cat (类 


如 下 location 指 定 了 一 致 性 f 
间 行 负载 均衡 。 


A) ， 如 果 没 有 ， 则 再 根据 请 求 uri 进 


location / { 
set $consistent key $arg cat; 

if ($consistent key = "") { 
set $consistent key $request uri 


) 


而 实际 我 们 是 通过 Lua 设 置 一 致 性 哈 希 key 。 


set by lua file $consistent key "lua balancing.lua"; 


lua balancing.lua 代码 。 

local consistent key - args.cat 

if not consistent key or consistent key -- '' then 
consistent key = ngx var.request uri 

end 


local value - balancing cache:get(consistent key) 
if not value then 


success, err - balancing cache:set(consistent key, 1, 60) 
else 

newval, err = balancing cache:incr(consistent key, 1) 
end 
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此 时 可 以 在 一 致 性 哈 硕 key 后 加 上 递增 的 计数 以 实现 类 似 轮 询 的 算法 。 
if newval > 5000 then 


consistent key = consistent key .. ' ' .. newval 
end 


least conn : 将 请 求 负载 均衡 到 最 少 活路 连接 的 上 游 服务 器 。 如 末 配 置 
的 服务 器 较 少 ， 则 将 转 而 使 用 基于 权重 的 轮 询 算 法 。 


Nginx 商 业 版 还 提供 了 least_time， 即 基于 最 小 平均 啊 应 时 间 进 行 负载 均 


2.3 AME 


主要 有 两 部 分 配置 : upstream server 和 proxy_pass。 


upstream backend { 
server 192.168.61.1:9080 max fails-2 fail timeout-10s weight=1; 
server 192.168.61.1:9090 max fails-2 fail timeout-10s weight-1; 
) 


通过 配置 上 游 服务 器 的 max_fails 和 fail _ timeout， 来 指定 每 个 上 游 服务 器 ， 
当 fail_timeout 时 间 内 失败 了 max_fails 次 请 求 ， 则 认为 该 上 游 服 务 器 不 可 


然后 将 摘 掉 该 上 游 服务 器 ，fail_timeout 时 间 后 会 再 次 将 该 服 
Sg LA SETS EUER AS s V RETI EX o 


location /test { 
proxy connect timeout 5s; 
proxy read timeout 5s; 
proxy send timeout 5s; 


proxy next upstream error timeout; 
proxy next upstream timeout 10s; 
proxy next upstream tries 2; 


proxy pass http://backend; 
add header upstream addr S$upstream addr; 


) 


然后 next _upstream 相 关 配 置 ， 当 遇 到 配置 的 销 误 时 ， 会 重 试 下 
— 6 EPIRI EY ° 


详细 配置 请 参考 第 6 章 中 代理 层 超时 与 重 试 机 制 的 Nginx 部 分 


2.4 ”健康 检查 


Nginx 对 上 游 服 务 咯 的 健康 检查 默认 采用 的 是 惰性 策略 ，Nginx 商 业 版 提 

Bt 了 health check 进行 主动 健康 检查 。 当 然 也 可 以 集成 

nginx upstream check module 
(https://github.com/yaoweibin/nginx upstream check module) 模块 来 进行 


主动 健康 检查 
nginx upstream check module 支持 TCP 心 跳 和 HTTP 心 跳 来 实现 健康 检 


f 


2.4.1 ”TCP 心跳 检查 


upstream backend { 
server 192.168.61.1:9080 weight=1; 
server 192.168.61.1:9090 weight=2; 
check interval=3000 rise-1 fall=3 timeout-2000 type-tcp; 


此 处 配置 使 用 TCP 进 行 心跳 检测 。 
interval: 检测 间隔 时 间 ， 此 处 配置 了 每 隔 3s 检 测 一 次 。 

fall: 检测 失败 多 少 次 后 ， 上 游 服务 器 被 标识 为 不 存活 。 

rise: 检测 成 功 多 少 次 后 ， 上 游 服务 器 被 标识 为 存活 ， 并 可 以 处 理 请 
‘timeout: 检测 请 求 超时 时 间 配 置 。 

2.4.2 HTTP 心跳 检查 


upstream backend { 


server 192.168.61.1:9080 weight=1; 
server 192.168.61.1:9090 weight=2; 


check interval-3000 rise-1 fall=3 timeout-2000 type=http; 
check http send "HEAD /status HTTP/1.0\r\n\r\n"; 
check http expect alive http 2xx http 3xx; 

} 


HTTP 心 跳 检 查 有 如 下 两 个 需要 额外 配置 。 
: check http send: 即 检查 时 发 的 HITP 请 求 内 容 。 


: check http expect alive: 当 上 游 服 务 器 返回 匹配 的 响应 状态 码 时 ， 则 
认为 上 游 服 务 右 存活。 

此 处 需要 注意 ， 检 查 间 隔 时 间 不 能 太 短 ， 否 则 可 能 因为 心跳 检查 包 太 多 
造成 上 游 服务 器 挂 掉 ， 同 时 要 设置 合理 的 超时 时 间 。 


本 文 使 用 的 是 openresty/1.11.2.1 (对 应 nginx-1.11.2) ， 安 装 Nginx 之 前 需 
要 先 打 nginx_upstream_check_module fh ] (check 1.9.2+.patch ) ， 到 
Nginx 目 录 下 执行 如 下 shell: 


patch -p0 < /usr/servers/nginx upstream check module- 
master/check_1.9.2+.patch ° 


如 果 不 安装 补丁 ， 那 么 nginx_upstream_check_module 模 块 是 不 工作 的 ， 建 
议 使 用 wireshark 抓 包 查 看 其 是 否 工 作 。 


2.5 “其 他 配置 
2.5.1 域名 上 游 服务 器 


upstream backend { 
server c0.3.ocn; 
server cl.3.cn; 


} 


在 Nginx 社 区 版 中 ， 是 在 Nginx 解 析 配 置 文件 的 阶段 将 域名 解析 成 IP 地 址 
并 记录 到 upstream 上 ， 当 这 两 个 域名 对 应 的 他 地址 发 生变 化 时 ， 该 
upstream 不 会 更 新 。Nginx 商 业 版 才 文 持 动态 更 新 。 


不 过 ，proxy_pass http://c0.3.cn 是 支持 动态 域名 解析 的 。 


2.5.2 ”备份 上 游 服 务 器 


upstream backend { 
server 192.168.61.1:9080 weight=1; 
server 192.168.61.1:9090 weight-2 backup; 


) 
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时 ， 流 量 可 以 转发 到 备 上 游 服务 器 ， 从 而 不 影响 用 户 请 求 处 理 。 


2.5.3 不 可 用 上 游 服务 器 


upstream backend { 
server 192.168.61.1:9080 weight=1; 
server 192.168.61.1:9090 weight=2 down; 
) 


9090 端 口上 游 服 务 器 配置 为 永久 不 可 用 ， 当 测试 或 者 机 器 出 现 故 障 时 ， 
暂时 通过 该 配置 临时 摘 掉 机 器 。 


2.6 ”长 连接 

此 处 只 涉及 如 何 配置 Nginx 与 上 游 服 务 器 的 长 连 车 返 ， 而 客户 端 与 Nginx 之 
间 的 长 连接 可 以 参考 位 置 第 6 草 的 相应 部 分 

可 以 通过 keepalive 指 令 配置 长 连接 数量 。 


upstream backend { 
server 192.168.61.1:9080 weight=1; 
server 192.168.61.1:9090 weight=2 backup; 
keepalive 100; 


} 
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大 数量 。 当 超出 这 个 数量 时 ， 最 近 最 少 使 用 的 连接 将 被 天 闭 。keepalive 指 
令 不 限制 Worker 进 程 与 上 游 服 务 器 的 总 连接 。 


如 采 想 要 跟 上 游 服 务 器 建立 长 连接 ， 则 一 定 别 志 了 以 下 配置 。 


location / { 
# 支 持 keep-alive 
proxy http version 1.1; 
proxy set header Connection ""; 
proxy pass http://backend; 

} 


如 果 是 http/1.0， 则 需要 配置 发 送 “Connection: Keep-Alive” 请 求 头 。 
上 游 服 务 器 不 要 筷 记 开启 长 连接 文 持 。 


fe B E , dX dl] & — F Nginx 是 如 何 实 现 keepalive 的 
(ngx http upstream keepalive module) , E 连接 时 的 部 分 代码 。 


ngx http upstream get keepalive peer(ngx peer connection t *pc, 
void *data) { 
//1. 首先 询问 负载 均衡 使 用 哪 台 服务 器 〈IP 和 端口 ) 


rc = kp-»original get peer(pc, kp->data); 


cache = &kp->conf->cache; 

//2. 轮 询 “空闲 连接 池 ? 

for (q - ngx queue head(cache); 
q != ngx queue sentinel (cache) ; 
q - ngx queue next (q)) 


item = ngx queue data(q, ngx http upstream keepalive cache t, queug) 
c = item->connection; 
//2.1. 如 果 “ 空 闲 连 接 池 ” 缓 存 的 连接 IP 和 端口 与 负载 均衡 到 的 IP 和 端口 相同 ， 
// 则 使 用 此 连接 
if (mx memn2cmp((u char *) &iten-»sockaddr, (uchar*) pe»sockaddr, 
item->socklen, pc->socklen) == 0) { 
//2.2 从 “空闲 连接 池 ” 移 除 此 连接 并 压 入 “释放 连接 池 ” 栈 顶 
ngx queue remove (q); 
ngx queue insert head(&kp-»conf-»free, q); 


goto found; 


} 
//3. 如 果 “ 空 闲 连 接 池 ”没有 可 用 的 长 连接 ， 将 创建 短 连 接 


return NGX OK; 


释放 连接 时 的 部 分 代码 如 下 。 


ngx http upstream free keepalive peer(ngx peer connection t *pc, 
void *data, ngx uint t state) { 
c = pc->connection;// 当 前 要 释放 的 连接 
/[1. 如 果 “ 释 放 连 接 池 ”没有 待 释 放 连 接 ， 那 么 需要 从 “空间 连 LM 腾 出 一 个 空间 给 新 
// 的 连接 使 用 〈 这 种 情况 存在 于 创建 连接 数 超出 了 连接 池 大 小 时 ， Me mE 
if (ngx_queue_empty (&kp->conf->free)) { 
q = ngx queue last(&kp-»conf-»cache); 
ngx queue remove (q); 
item - ngx queue data(q, ngx http upstream keepalive cache t, 


queue); 
ngx http upstream keepalive close (item-»connection); 
} else (//2. 从 “释放 连接 池 ” 释 放 一 个 连接 
q = ngx_queue_head(&kp->conf->free) ; 
ngx_queue_remove (q); 
item = ngx queue data(q, ngx http upstream keepalive cache t, 
queue); 


) 

//3. 将 当前 连接 压 入 “空闲 连接 池 ” 栈 项 供 下 次 使 用 
ngx queue insert head(&kp-»conf-»cache, q); 
item->connection = c; 
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配置 不 会 限制 Worker 进 程 可 以 打开 的 总 连接 数 ( 超 了 的 作为 短 连接 ) 。 
另外 ， 连 接 池 一 定 要 根据 实际 场景 合理 进行 设置 。 


空闲 连接 池 太 小 ， 连 接 不 够 用 ， 需 要 不 断 建 连 接 。 
空 内 连接 池 太 大 ， 空 几 连 接 太 多 ， 还 没 使 用 束 超 时 。 
另外 ， 建 议 只 对 小 报 文 开 局 长 连接 。 
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1. 全 局 配置 (proxy cache) 


proxy buffering 

proxy buffer size 
proxy buffers 

proxy busy buffers size 


proxy temp file write size 
proxy cache lock 
proxy cache lock timeout 


proxy temp path 
proxy cache path 


proxy connect timeout 3s; 
proxy read timeout 58; 
proxy send timeout 58; 


on; 
4k; 

512 4k; 

64k; 

256k; 

on; 

200ms; 

/tmpfs/proxy temp; 

/tmpfs/proxy cache levels-1:2 keys zone 
-cache:512m inactive-5m max size-8g; 


开启 proxy buffer， 缓 存 内容 将 存放 在 tmpfs (内 存 文件 系统 ) 以 提升 性 


能 ， 设 置 超时 时 间 。 
2.location 配 置 


location ~ ^/backend/(.*)$ ( 


# 设 置 一 致 性 哈 希 负载 均衡 key 
set by lua file $consistent key "/export/App/c.3.cn/lua/lua 


balancing backend.properties"; 


# 失 败 重 试 配置 

proxy next upstream error timeout http 500 http 502 http 504; 
proxy next upstream timeout 2s; 

proxy next upstream tries 2; 


# 请 求 上 游 服务 器 使 用 GET 方法 〈 不 管 请 求 是 什么 方法 ) 
proxy method GET; 

# 不 给 上 游 服务 器 传递 请 求 体 

proxy pass request body off; 


# 不 给 上 游 服务 器 传递 请 求 头 

proxy pass request headers off; 

# 设 置 上 游 服务 器 的 哪些 啊 应 头 不 发 送 给 客户 端 

proxy hide header Vary; 

EXE keep-alive 

proxy http version 1.1; 

proxy set header Connection ""; 

# 给 上 游 服 务 器 传递 Referer、Cookie 和 Host ( 按 需 传递 ) 

proxy set header Referer Shttp referer; 

proxy set header Cookie S$http cookie; 

proxy set header Host web.c.3.local; 

proxy pass http://backend /$1$is args$args; 
} 


我 们 开启 T proxy_pass_request_body FH proxy_pass_request_headers, 44 it 
[A] EJ HR ae Fe ETA AANA, MA m Et ERA ds P S6 TK AB 
B ， 也 不 需要 解析 ; 如 果 需 要 传递 ， 则 使 用 proxy_set_header 按 需 传递 即 


我 们 还 可 以 通过 如 下 配置 来 开启 gzip 文 持 ， 减 少 网 络 传输 的 数据 包 大 小 。 


gzip on; 

gzip min length lk; 

gzip buffers 16 16k; 

gzip http version 1.0; 

gzip proxied any; 

gzip comp level 2; 

gzip types text/plain application/x-javascript text/css 
application/xml; 

gzip vary on; 


对 于 内 容 型 响应 建议 开局 gzip 压 缩 ，gzip_comp_level 压 缩 级 别 要 根据 实际 
压 测 来 决定 (带宽 和 吞吐 量 之 间 的 抉择 ) 。 


2.8 ” HTTP 动态 负载 均衡 


如 上 的 负载 均衡 实现 中 ， 每 次 upstream 列 表 有 变更 ， 都 需要 到 服务 顺 进 行 
修改 ， 首 先是 管理 容易 出 现 问 题 ， 而 且 对 于 upstream 服 务 上 线 无 法 自动 注 
及 到 nginx upstream 列 表 。 因 此 ， 我 们 需要 一 种 服务 注册 ， 可 以 将 upstream 
动态 注册 到 Nginx 上 ， 从 而 实现 upstream 服 务 的 目 动 发 现 。 


Consul 是 一 款 开 源 的 分 布 式 服务 注册 与 发 现 系 统 ， 通 过 HTTP API 可 以 使 
得 服务 注册 、 发现 实现 起 来 非常 简单 ， 它 文 持 如 下 特性 。 


- 服务 注册 :， 服 务实 现 者 可 以 通过 HTTP API 或 DNS 方式 ， 将 服务 注册 到 


Consul ° 


. 服务 发 现 : 服务 消费 者 可 以 通过 HTTP API 或 DNS 方式 ， 从 Consu 获 取 
服务 的 IP 和 PORT 。 


` 故障 检测 : 支持 如 TCP、HTTP 等 方式 的 健康 检查 机 制 ， 从 而 当 服 务 有 
故障 时 目 动 摘除 。 


. K/V 存 储 : 使 用 K/V 存 储 实 现 动 态 配 置 中 心 ， 其 使 用 HTTP 长 轮 询 实现 变 
更 触发 和 配置 更 改 。 


` 多 数据 中 心 : 支持 多 数据 中 心 ， 可 以 按照 数据 中 心 注册 和 发 现 服务 ， 即 
eee 使 用 多 数据 中 心 集群 还 可 以 避免 单数 据 中 心 
N JN EH 9 


.Raft 算 法 : Consul 使 用 Raft 算 法 实现 集群 数据 一 致 性 。 


通过 Consul 可 以 管理 服务 注册 与 发 现 ， 接 下 来 需要 有 一 个 与 Nginx 部 署 在 
同一 台 机 器 的 Agent 来 实现 Nginx 配 置 更 改 和 Nginx 重 启 功 能 。 我 们 有 
Confd 或 者 Consul-template 两 个 选择 ， 而 Consul-template 是 Consul 官 方 提供 
的 ， 我 们 就 选择 它 了 。 其 使 用 HTTP 长 轮 询 实 现 变更 触发 和 配置 更 改 (使 
用 Consul 的 watch 命 令 实现 ) 。 也 就 是 说 ， 我 们 使 用 Consul-template 实 现 配 
置 模板 ， 然 后 拉 取 Consu] 配 置 泻 染 模板 来 生成 Nginx 实 际 配置 。 


除 Consul 外 ， 还 有 一 个 选择 是 etcd3， 其 使 用 了 gRPC 和 protobuf 可 以 说 是 一 
个 亮点 。 不 过 ，etcd3 目 前 没有 提供 多 数据 中 心 、 故 障 检测 、Web 管 理 界 
面 o 


2.8.1 Consul+Consul-template 


搂 下 来 ， 让 我 们 看 一 下 如 何 来 实现 Nginx 动 态 配置 。 首 先 ， 下 图 是 我 们 要 
实现 的 架构 图 。 


r 一 一 一 一 一 丁 一 一 一 一 、 负 载 均衡 ~ — — —4 
| | | 
| | | 
Y Y | 


upstream server1 upstream server2 Nginx 


= 、 注 册 / 摘 = 


3、 修 改 upstream 4、 重 启 Nginx 


Consul Server “二 -一 一 2、 拉 取 配 置 


Consul-template 


1.2、 注 册 / 摘 除 


Consul 管 理 后 台 


首先 ，upstream 服 务 启动 ， 我 们 通过 管理 后 台 辐 Consule 注 册 服 务 。 


我 们 需要 在 Nginx 机 絮 上 部 署 并 启动 Consul-template Agent， 其 通过 长 轮 询 
监听 服务 变更 。 


Consul-template 监 听 到 变更 后 ， 动 态 修改 upstream 列 表 。 
Consul-template 修 改 完 upstream 列 表 后 ， 调 用 重启 Nginx 脚 本 重启 Nginx ° 


整个 实现 过 程 还 是 比较 简单 的 ， 不 过 ， 实 际 生 产 环 境 要 复杂 得 多 。 我 们 
使 用 了 Consul 0.7.0 和 Consul-template 0.16.0 来 实现 。 


1.Consul-Server 


首先 我 们 要 启动 Consul-Server 。 


./consul agent -server -bootstrap-expect 1 -data-dir /tmp/consul 
-bind 0.0.0.0 -client 0.0.0.0 


此 处 需要 使 用 data-dir 指 定 Agent 状 态 存储 位 置 ，bind 指 定 集群 通信 的 地 
址 ，client 指 定 客户 端 通 信 的 地 址 (如 Consul-template 与 Consul 通 信 ) ° 
启动 时 还 可 以 使 用 -ui-dir /ui/& xe Consul Web UI 目录 ， 实 现 通 过 Web Ul 
理 Consul， 然 后 访问 如 http://127.0.0.1:8500 即 可 看 到 控制 界面 。 


© 192.168.61.129 


E 
ii item_jd_tomcat 
fi mysql 
使 用 如 下 HTTP API 注 册 服 务 。 
curl -X PUT http://127.0.0.1:8500/v1/catalog/register -d '{"Datacenter": "dc1", 
"Node": "tomcat", "Address": "192.168.1.1"","Service": t Id" 


"192.168.1.1:8080", "Service": "item jd tomcat'", "tags": ["dev"], "Port": 
8080) 


curl -X PUT http://127.0.0.1:8500/v1/catalog/register -d '{"Datacenter": "dc1", 
"Node": "tomcat", "Address": "192.168.1.2" ,"Service": {"Id" 
"192.168.1.1:8090", "Service": "item_jd_tomcat", "tags": ["dev"], "Port": 
8090} }' 


Datacenter 指 定数 据 中 心 ，Address 指 定 服务 IP， Service.Id 指 定 服务 唯一 标 
识 ，Service.Service 指 定 服务 分 组 ，Service.tags 指 定 服务 标签 (如 测试 环 
境 、 预 发 环境 等 ) ，S$ervice.Port 指 定 服务 器 端口 。 

通过 如 下 HTTP API 摘 除 服务 。 


curl -X PUT http://127.0.0.1:8500/v1/catalog/deregister- d '{"Datacenter": 
"dc1", "Node": "tomcat", "ServiceID" : "192.168.1.1:8080" }' 


通过 如 下 HTTP API 发 现 服务 。 
curl http://127.0.0.1:8500/v1/catalog/service/item jd tomcat 


可 以 看 到 ， 通 过 这 几 个 HTTP API 可 以 实现 服务 注册 与 发 现 。 更 多 API 请 
参考 https://www.consul.io/docs/agent/http.html 。 


2.Consul-template 


接 下 来 我 们 需要 在 Consul-template 机 器 上 添加 一 份 配置 模板 


item.jd.tomcat.ctmpl ° 


upstream item jd tomcat { 
server 127.0.0.1:1111; # 占 位 server， 必 须 有 一 个 server， 否 则 无 法 启动 
{{range service "dev.item jd tomcat@dcl"}} 
server {{.Address}}:{{.Port}} weight=1; 
{ {end} } 


} 


service 指 定格 式 为 : 标签 .服务 @ 数 据 中 心 ， 然 后 通过 循环 输出 Address 和 
Port， 从 而 生成 Nginx upstream 配 置 。 


局 动 Consul-template ° 
./consul-template -consul 127.0.0.1:8500 \ 


-template 
Jitem.jd.tomcat.ctmpl:/usr/servers/nginx/conf/domains/item.jd.tomcat:" /restart 
.sh" 


使 用 consul 指 定 Consul 服 务 器 客户 问 通 信 地 址 ，template 格 式 是 “配置 模板 : 
22 UEM 即 通过 配置 模板 更 新 目标 配置 文件 ， 然 后 调用 脚本 
m Nginx ° 


直接 通过 Nginx includef§ <¥ /usr/servers/nginx/conf/domains/item.jd.tomcat 


包含 到 nginx.conf 配 置 文件 即 可 ，restart,sh 脚 本 代码 如 下 所 示 。 


#!/bin/bash 
ps -fe|grep nginx |grep -v grep 
if [ $? -ne 0 ] 
then 
sudo /usr/servers/nginx/sbin/nginx 
echo "nginx start" 
else 
sudo /usr/servers/nginx/sbin/nginx -s reload 
echo "nginx reload" 
fi 


即 如 果 Nginx 没 有 启动 ， 则 启动 ， 否 则 重启 。 
3.Java 服 务 


建议 配合 Spring Boot+Consul Java Client S: Il, 3X fi] ( FH AY Consul Java 
Client 如 下 。 


<dependency> 
<groupId>com.orbitz.consul</groupId> 
<artifactId>consul-client</artifactId> 
<version>0.12.8</version> 
</dependency> 


如 下 代码 是 进行 服务 注册 与 摘除 。 


public static void main(String[] args) ( 
/ | ADRAR (Hl Tomcat) 
SpringApplication.run(Bootstrap.class, args); 
/ /服务 注册 
Consul consul = Consul.builder().withHostAndPort (HostAndPort. fromString 
("192.168.61.129:8500")) .build(); 
final AgentClient agentClient = consul.agentClient(); 


String service - "item jd tomcat"; 
String address - "192.168.61.1"; 
String tag = "dev"; 
int port - 9080; 
final String serviceId = address + ":" + port; 
ImmutableRegistration.Builder builder = ImmtableRegistration.builder(); 
builder.id(serviceId).name (service) 
.address (address) .port (port) .addTags (tag); 

agentClient.register (builder.build()); 
//JVM 停止 时 摘除 服务 
Runtime.getRuntime().addShutdownHook (new Thread() { 

@Override 

public void run() { 

agentClient.deregister(serviceld) ; 


在 Spring Boot 局 动 后 进行 服务 注册 ， 然 后 在 JVM 停 止 时 进行 服 


务 
到 此 我 们 束 实 现 了 动态 upstream 负 载 均 衡 ，upstream 服 务 局 动 后 目 动 注册 
到 Nginx，upstream 服 务 停止 时 ， 目 动 从 Nginx 上 摘除 。 


通 过 Consul+Consul-template 方 式 ， 次 发 现 配 置 变更 都 需要 reload 
nginx， 而 reload 是 有 一 定 损耗 的 。 而 且 ， 如 果 你 需要 长 连接 文 持 的 话 ， 那 
么 当 reload nginx 时 长 连接 所 在 worker 进 程 会 进行 优雅 退出 ， 并 当 该 worker 
进程 上 的 所 有 连接 都 释放 时 ， 进 程 才 真 正 退 出 (表现 为 worker 进 程 处 于 
worker process is shutting down) 。 因 此 ， 如 果 能 做 到 不 reload 就 能 动态 更 
改 upstream， 那 么 就 完美 了。 对 于 社区 版 Nginx 目 前 有 三 个 选择 : Tengine 
的 Dyups 模 块 、 微 博 的 Upsync 和 使 用 i us p s 。 微 博 使 
用 Upsync+Consul 实 现 动态 负载 均衡 ， 而 又 拍 云 使 用 其 开源 的 slardar 
(Consul + balancer by lua) 实现 动态 负载 均衡 。 


2.8.2 Consul+OpenResty 
使 用 Consu 注 册 服 务 ， 使 用 OpenResty balancer_by_lua 实 现 无 reload 动 态 负 
载 均 衡 ， 架 构 如 下 所 示 。 


3、balancer_by_lua 
P À——Ü M99 ———— € -一 一 


| | 动态 负载 均衡 


Y Y 


| 
| 
| 
upstream server1 upstream server2 | 
| 
| 


m 注册 / 摘 = — 
| shared dict 


.二 十 > Hy Wo E | 2.2、 实 时 更 新 到 
Consul Server < 定期 拉 取 配 a init_by_lua - ned 
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init worker by lua | 


Nginx 


1.2、 注 册 / 摘 除 
| 


Consul 管 理 后 台 


1. 通 过 upstream server 启 动 /停止 时 注册 服务 ， 或 者 通过 Consul 管 理 后 台 注 
册 服 务 。 


2.Nginx 启 动 时 会 调用 tnit by dua. 启动 时 拉 取 配置 ， 并 更 新 到 共享 字典 来 
ff tif upstream 7] z& ; 然后 通过 init worker by lua/H ZJXE P] 28, 4E HH 
Consul 拉 取 配 置 并 实时 更 新 到 共享 字典 。 


3.balancer_by_lua 使 用 共享 字典 存储 的 upstream 列 表 进 行动 态 负 载 均衡 。 


dyna upstreams.lua 模块 
local http = require("socket.http") 
local ltnl12 = require("ltnl12") 
local cjson = require "cjson" 
local function update upstreams() 
local resp = {} 
http.request( 
url= 
"http://192.168.61.129:8500/v1/catalog/service/item jd tomcat", 
Sink = ltnl2.sink.table (resp) 
) 


resp - table.concat (resp) 


resp = cjson.decode (resp) 


local upstreams = {{ip="127.0.0.1", port=1111}} 
for i, v in ipairs(resp) do 

upstreams[itl] = {ip=v.Address, port-v.ServicePort] 
end 


ngx.shared.upstream list:set ("item jd tomcat", cjson.encode (upstreams) ) 
end 


local function get_upstreams () 
local upstreams str = ngx.shared.upstream list:get ("item jd tomcat") 
end 


local M= { 
update_upstreams = update_upstreams, 
get_upstreams = get_upstreams 


} 


ii Iuasockets £t i&Consul?& A MAR, update upstreamsHi F Æ 3irupstream 
列表 ，get_upstreams 用 于 返回 upstream 列 表 ， 此 处 可 以 考虑 worker 进 程 级 
别 的 缓存 ， 减 少 因 为 json 的 反 序列 化 造成 的 性 能 开销 。 


还 要 注意 我 们 使 用 的 luasocket 是 阻塞 API， 为 截至 本 书 出 版 时 ， 
OpenResty 在 init_by_lua 和 init_worker_by_lua 不 支持 Cosocket (未 来 会 添加 
支持 ) ， 所 以 我 们 只 能 使 用 luasocket， 但 是 ， 注 意 这 可 能 会 阻塞 我 们 的 服 
务 ， 使 用 时 要 慎重 。 


init * by lua 配置 
# 存 储 upstream 列表 的 共享 字典 


lua shared dict upstream list 10m; 


#Nginx Master 进程 加 载 配置 文件 时 执行 ， 用 于 第 一 次 初始 化 配置 
init by lua block { 
local dyna upstreams - require "dyna upstreams"; 
dyna upstreams.update upstreams(); 
} 
#Nginx Worker 进程 调度 ， 使 用 ngx .timer.at 定时 拉 取 配置 
init worker by lua block ( 
local dyna upstreams - require "dyna upstreams"; 
local handle = nil; 
handle = function () 
--TODO :控制 每 次 只 有 一 个 worker 执行 
dyna upstreams.update upstreams(); 
ngx.timer.at(5, handle); 
end 
ngx.timer.at(5, handle); 


) 


init worker by luaxé&T Nginx Worker 进 程 都 会 执行 的 代码 ， 所 以 实际 实 
现时 可 考虑 使 用 锁 机 制 ， 保 证 一 次 只 有 一 个 人 处 理 配 置 拉 取 。 另 外 
ngx.timerat 是 定时 轮 询 ， 不 是 走 的 长 轮 询 ， 有 一 定 的 时 延 。 有 个 解决 方 
案 ， 是 在 Nginx 上 暴露 HTTP API， 通 过 主动 推送 的 方式 解决 。 


d 4. balancer by lua 
J 1 动态 负载 均衡 


1.1、 注 册 / 摘 除 


HTTP API 


3.2、 实 时 更 新 


到 共享 字典 


Consul Server 


1.2、 注 册 / 摘 除 


2、 拉 取 配 置 


Consul 管 理 后 台 


Agent 可 以 长 轮 询 拉 取 ， 然 后 调用 HTTP API 推 送 到 Nginx 上 ，Agent 可 以 部 
署 在 Nginx 本 机 或 者 远程 。 


对 于 拉 取 的 配置 ， 除 了 放 在 内 存 里 ， 请 考虑 在 本 地 文件 系统 中 存储 一 
份 ， 在 网 络 出 问题 时 作为 托 底 。 


upstream 配置 
upstream item jd tomcat { 
server 0.0.0.1; # 占 位 server 
balancer by lua block { 
local balancer = require "ngx.balancer" 
local dyna upstreams = require "dyna upstreams"; 
local upstreams - dyna upstreams.get upstreams(); 
local ip port = upstreams[math.random(l,table.getn(upstreams)) | 


ngx.log(ngx.ERR, "current : =============" ji 
math.random(l,table.getn (upstreams) ) ) 
balancer.set current peer(ip port.ip, ip port.port) 
) 
} 


获取 upstream 列 表 ， 实 现 目 己 的 负载 均衡 算法 ， 通 过 ngx.balancer API 进 行 
动态 设置 本 次 upstream server。 通 过 balancer_by_lua 除 可 以 实现 动态 负载 
均衡 外 ， 还 可 以 实现 个 性 化 负载 均衡 算法 。 


最 后 ， 记 得 使 用 lua-resty-upstream-healthcheck 模 块 进行 健康 检查 © 


2.9 Nginx 四 层 负载 均衡 


Nginx 1.9.0 版 本 起 文 持 四 层 人 负载 均衡 ， 从 而 使 得 Nginx 变 得 更 加 强大 。 目 
前 ， 四 层 软 件 负载 均衡 锅 用 得 比较 多 的 是 HaProxy; 而 Nginx 也 文 持 四 层 
负载 均衡 ， 一 般 场 景 我 们 使 用 Nginx 一 站 式 解 决 方案 就 够 了 。 本 部 分 将 以 
TCP 四 层 负载 均衡 进行 示例 讲解 。 


2.9.1 静态 负载 均衡 


在 默认 情况 下 ，ngx_stream_core_module 是 没有 启用 的 ， 需 要 在 安装 
Nginx 时 ， 添 加 --with-stream 配 置 参数 启用 » 


./configure --prefix-/usr/servers --with-stream 


1.stream 指 令 


我 们 配置 HTTP 负 载 均 衡 时 ， 都 是 配置 在 http 指 令 下 ， 而 四 层 负载 均衡 是 
配置 在 stream 指 令 下 。 


stream { 
upstream mysql backend { 


} 
server { 


2.upstream 配 置 
类 似 于 http upstream 配 置 ， 配 置 如 下 。 


upstream mysql. backend { 


server 192.168.0.10:3306 max fails-2 fail timeout-10s weight=1; 
server 192.168.0.11:3306 max fails-2 fail timeout-10s weight=1; 
least conn; 


) 


进行 失败 重 试 、 惰 性 健康 检查 、 负 载 均衡 算法 相关 配置 ， 与 HITP 人 负载 均 
不 再 重复 解释 。 此 处 我 们 配置 实现 了 两 个 数据 库 服务 器 的 
TCP 人 负载 均衡 。 


3.server 配 置 


server { 
# 监 听 端 口 
listen 3308; 
# 失 败 重 试 
proxy next upstream on; 
proxy next upstream timeout 0; 
proxy next upstream tries 0; 
# 超 时 配置 
proxy connect timeout 1s; 
proxy timeout 1m; 
# 限 速配 置 
proxy upload rate 0; 
proxy download rate 0; 
t LUE ARS as 
proxy pass mysql backend; 
) 


listen 指 令 指定 监听 的 端口 ， 默 认 TCP 协 议 ， 如 果 需 要 UDP ， 则 可 以 配 
“listen 3308 udp;” ° 


proxy_next_upstream* 与 之 前 讲 过 的 HTTP 负载 均衡 类 似 ， 不 再 重复 解释 © 
proxy. connect timeout fic E <j E wf Hk 25 ae XE Be IBI HD. BRU 60s © 
proxy_timeout 配 置 与 客户 问 或 上 游 服 务 器 连接 的 两 次 成 功 读 / 写 操作 的 超 
时 时 则 ， 如 果 超 时 ， 将 自动 断 开 连 授 ， 即 连接 存活 时 间 ， 通 过 它 可 以 释 
放 和 那些 不 活跃 的 连接 ， 默 认 10 分 钟 。 proxy upload rate 和 
proxy_download_rate 分 别 配置 从 客户 端 读 数据 和 从 上 游 服 务 器 读数 据 的 速 
率 ， 单 位 为 每 秒 字 节 数 ， 默 认为 0， 不 限 速 。 


接 下 来 就 可 以 连接 Nginx 的 3308 端 口 ， 访 问 我 们 的 数据 库 服务 器 了 。 


目前 的 配置 都 是 静态 配置 ， 像 数据 库 连 接 一 般 部 是 使 用 长 连接 ， 如 采 重 
局 Nginx 服 务 器 ， 则 会 看 到 如 下 Worker 进 程 一 直 不 退出 。 


Nobody 10268 ...... nginx: worker process is shutting down 


这 是 因为 Worker 维 持 的 长 连接 一 直 在 使 用 ， 所 以 无 法 退出 ， 解 决 办 法 只 
能 是 杀 掉 该 进程 。 


当然 ,一 般 情况 下 是 因为 需要 动态 添加 /删除 上 游 服 务 嚣 ， 才 需要 重启 
Nginx， 像 HTTP 动 态 人 负载 均衡 那样 。 如 果 能 做 到 动态 负载 均衡 ， 则 一 大 
部 分 问题 就 解决 了 。 


一 个 选择 是 购买 Nginxu 商 业 版 ， 另 一 个 选择 是 使 用 nginx-stream-upsync- 
module, H 前 ， OpenResty fe £t 的 stream-lua-nginx-module 尚未 实现 
balancer_by_lua 特 性 ， 因 此 暂时 无 法 使 用 。 当 前 开源 选择 可 以 使 用 nginx- 


stream-upsync-module ° 


2.9.2 ”动态 负载 均衡 


nginx-stream-upsync-module 有 一 个 兄弟 nginx-upsync-module ， 其 提供 了 
HTTP 七 层 动 态 负载 均衡 ， 动 态 更 新 上 游 服务 器 不 需要 reload nginx。 当 前 
最 新 版 本 是 基于 Nginx 1.9.10 开 发 的 ， 因 此 兼容 1.9.10+ 版 本 。 其 提供 了 基 
于 consul 和 etcd 进 行动 态 更 新 上 游 服 务 絮 实现 。 本 部 分 基于 Nginx 1.9.10 版 
本 和 consul 配 置 中 心 进行 演示 。 


首先 ， 需 要 下 载 并 添加 nginx-stream-upsync-module 模 块 最 新 版 本 。 


./configure --prefix=/usr/servers --with-stream --add-module=./nginxstream- 
upsync-module 


1.upstream 配 置 


upstream mysql backend { 
server 127.0.0.1:1111; # 占 位 server 
upsync 127.0.0.1:8500/vl/kv/upstreams/mysql backend upsync timeout =6m 
upsync interval-500ms upsync type-consul strong dependency-off; 
upsync dump path /usr/servers/nginx/conf/mysql backend.conf; 


) 


upsync 指 令 指 定 从 consul 哪 个 路 径 拉 取 上 游 服务 器 配置 ，upsync_timeout 配 
置 从 consu 拉 取 上 游 服 务 需 配置 的 超时 时 间 ; upsync_interval 配 置 从 consul 
拉 取 上 游 服务 器 配置 的 间 隅 时 间 ; upsync_type 指 定 使 用 consu 配 置 服务 
at; strong_dependency 配 置 nginx 在 启动 时 是 否 强制 依赖 配置 服务 器 ， 如 
采 配 置 为 on， 则 拉 取 配置 失败 时 nginx 启 动 同 样 失败 。 


upsync_dump_path 指 定 从 consul 拉 取 的 上 游 服 务 絮 后 持久 化 到 的 位 置 ， 这 
样 即使 consul 服 务 器 出 问题 了 ， 本 地 还 有 一 个 备份 。 


2. 从 Consul 添 加 上 游 服 务 器 


curl -X PUT -d "{\"weight\":1, \"max fails\":2, \"fail_timeout\":10}" 
http://127.0.0.1:8500/vl/kv/ upstreams /mysql backend/ 10.0.0.24:3306 

curl -X PUT -d "{\"weight\":1, \"max failsV':2, \"fail_timeout\":10}" 
http://127.0.0.1:8500/v1/ kv/upstreams/mysql backend/192.168.0.11:3306 


3. 从 Consul 删 除 上 游 服务 器 


curl -X D ELETE http://127.0.0.1:8500/v1/kv/upstreams/mysql backend/ 
192.168.0.11:3306 


4.upstream, show 


server { 
listen 1234; 
upstream show; 


) 


ft ^ E upstream show 指令 后 , 可 以 3i 过 cud 
http://127.0.0.1:1234/upstream_show 来 查看 当前 动态 负载 均衡 上 游 服务 器 
列表 。 


到 此 动态 负载 均衡 就 配置 完成 了 ， 我 们 已 讲解 完 动 态 深 加 / 删 除 上 游 服务 
右 。 在 实际 使 用 时 ， 请 进行 压 测 来 评测 其 稳定 性 。 在 实际 应 用 中 ， 更 多 
n 因此 ， 还 是 要 根据 目 己 的 场景 来 选择 


参考 资料 


[1] http://nginx.org/en/docs/http/ngx http upstream module.html 


[2] http://nginx.org/en/docs/stream/ngx stream upstream module.html 


3 ”隔离 术 


隔离 是 指 将 系统 或 资源 分 割 开 ， 系 统 隔离 是 为 了 在 系统 发 生 故 障 时 ， 能 
限定 传播 范围 和 影响 范围 ， 即 发 生 故 障 后 不 会 出 现 滚雪球 效应 ， 从 而 保 
证 只 有 出 间 题 的 服务 不 可 用 ， 其 他 服务 还 是 可 用 的 。 资 源 隔 离 通过 隔离 
来 减少 资源 竞争 ， 保 障 服务 间 的 相互 不 影响 和 可 用 性 。 笔 者 遇 到 比较 多 
的 隔离 手段 有 线程 隔离 、 进 程 隔离 、 集 群 隔离 、 机 房 隔离 、 读 写 隔离 、 


快慢 隔离 、 动 静 隔 离 、 疏 虫 隔离 等 。 出 现 系统 问题 时 ， 可 以 考虑 负载 均 
衡 路 由 、 目 动 /手动 切换 分 组 或 者 降级 等 手段 来 保障 可 用 性 。 


3.1 ”线程 隔离 


线程 隔离 主要 是 指 线程 池 隔 离 ， 在 实际 使 用 时 ， 我 们 会 把 请 求 分 类 ， 然 
后 交 给 不 同 的 线程 池 处 理 。 当 一 种 业务 的 请 求 处 理发 生 问题 时 ， 不 会 将 
故障 扩散 到 其 他 线程 池 ， 从 而 保证 其 他 服务 可 用 。 


核心 业务 核心 业务 业务 
队列 线程 2 | 业务 处 理 | | 生成 响应 


was | Tomcat | sa a 
一 HTTP 请 求 单线 程 请 求解 析 


业务 处 理 | | 生成 响应 


非 核 心 业务 核心 业务 
队列 线程 池 


务 处 理 


我 们 会 根据 服务 等 级 划分 两 个 线程 池 ， 以 下 是 池 的 抽象 。 


<bean id-"zeroLevelAsyncContext" 
class-"com.jd.noah.base.web. DynamicAsyncContext" 
destroy-method-"stop"» 
<property name-"asyncTimeoutInSeconds" 
value-"$(zero.level.request.async.timeout.seconds)"/» 
<property name-"poolSize" 
value-"$(zero.level.request.async.pool.size)"/» 
<property name="keepAliveTimeInSeconds" 
value="${zero.level.request.async.keepalive.seconds}"/> 
<property name="queueCapacity" 
value="${zero.level.request.async.queue.capacity}"/> 
</bean> 
<bean id="oneLevelAsyncContext" 
class="com.jd.noah.base.web.DynamicAsyncContext" 
destroy-method="stop"> 
<property name-"asyncTimeoutInSeconds" 
value="S${one.level.request.async.timeout.seconds}"/> 
<property name="poolSize" 
value="${one.level.request.async.pool.size}"/> 
<property name="keepAliveTimeInSeconds" 
value="${one.level.request.async.keepalive.seconds}"/> 
<property name="queueCapacity" 
value="${one.level.request.async.queue.capacity}"/> 
</bean> 


3.2 ”进程 隔离 


在 公司 发 展 初 期 一般 是 先进 行 从 和 零 到 一 ， 不 会 一 上 来 束 进 行 系统 拆 
D, AERAN RE 些 大 而 全 的 系统 ， 系 统 中 的 一 个 模块 /功能 出 现 问 
题 ， 整 个 系统 束 不 可 用 了 。 首 先 ， 想 到 的 解决 方案 是 通过 部 署 多 个 实 

例 ， 通 过 负载 均衡 进行 路 由 转发 。 但 是 ， 这 种 情况 无 法 避免 某 个 模块 因 
BUG 而 出 现 如 OOM 寻 致 整个 系统 不 可 用 的 风险 。 因 此 ， 此 种 方案 只 是 一 

个 过 渡 ， eS m UE oos 
离 。 通 过 进程 隔离 使 得 某 一 个 子 系统 出 现 问题 时 不 会 影响 到 其 他 子 系 
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3.3 ”集群 隔离 


随 着 系统 的 发 展 ， 单 实例 服务 无 法 满足 需求 ， 此 时 需要 服务 化 技术 ， 通 
过 部 署 多 个 服务 形成 服务 集群 ， 来 近 升 系统 容量 ， 如 下 图 所 示 。 


商品 详情 页 服务 


购物 车 服务 


随 着 调用 方 的 增多 ， 当 秒杀 服务 被 刷 会 影响 到 其 他 服务 的 稳定 性 时 ， 应 
该 考虑 为 秒杀 提供 单独 的 服务 集群 ， 即 为 服务 分 组 ， 这 样 当 某 一 个 分 组 
出 现 问题 时 ， 不 会 影响 到 其 他 分 组 ， 从 而 实现 了 故障 隔离 ， 如 下 图 所 
ZR œ 


商品 服务 一 分 组 1 
实例 1 


商品 服务 一 分 组 2 


实例 1 | 


比如 ， 注 册 生 产 者 时 提供 分 组 名 。 


商品 详情 页 服务 
订单 服务 
购物 车 服务 


秒杀 服务 


<jsf:provider id-"myService" interface="com.jd.MyService" alias="${ 分 组 
4 }" ref="myServiceImpl"/> 


消费 时 使 用 相关 的 分 组 名 即 可 。 


<jsf:consumer id="myService" interface="com.jd.MyService" alias="${ 分 组 


名 }"/> 


3.4 ”机房 隔离 


随 着 对 系统 可 用 性 的 要 求 ， 会 进行 多 机 房 部 署 ， 每 个 机 房 的 服务 都 有 上 自 
己 的 服务 分 组 ， 本 机 房 的 服务 应 该 只 调用 本 机 房 服务 ， 不 进行 踪 机 房 调 
用 。 其 中 ， 一 个 机 房 服 务 发 生 问题 时 ， 可 以 通过 DNS/ 负 载 均 衡 将 请 求全 
ARZA HJ) ARTE ° 


商品 服务 一 机 房 1- 分 组 1 
实例 1 


| 实例 2 | 


商品 服务 一 机 房 2- 分 组 2 


实例 1 


实例 2 


一 种 办 法 是 根据 IP 〈 不 同 机 房 卫 段 不 一 样 ) 自动 分 组 ， 还 有 一 种 较 灵活 的 
办 法 是 通过 在 分 组 名 中 加 上 机 房 名 。 


<jsf:provider id="myService" interface="com.jd.MyService" alias="${ 分 组 
名 }-${ 机 房 }" ref="myServiceImpl"/> 


<jsf:consumer id="myService" interface="com.jd.MyService" alias="${ 分 组 


4 -SUPUS Y 


3.5 EZB 


如 下 图 所 示 ， 通 过 主 从 模式 将 读 和 写 集群 分 离 ， 读 服务 只 从 Redis 集 群 获 
取 数 据 ， 当 主 Redis 集 群 出 现 问题 时 ， 从 Redis 集 群 还 是 可 用 的 ， 从 而 不 影 
啊 用 户 访 问 。 而 当 从 Redis 集 群 出 现 问 题 时 ， 可 以 进行 其 他 集群 的 重 试 。 


机 房 A 
从 Redis 集 群 


-- 先 读 取 从 
status, resp = slave get (key) 
if status == STATUS OK then 


return status, value 
end 


-- 如 果 从 获取 失败 了 ， 从 主 获取 


status, resp = master get (key) 


3.6 “动静 隔离 


当 用 户 访 问 如 结算 页 时 ， 如 有 末 JS/CSS 等 静态 资源 也 在 结算 页 系统 中 时 ， 
很 可 能 因为 访问 量 太 大 导致 带宽 被 打 满 ， 从 而 出 现 不 可 用 。 


| 
用 户 请 求 
v 


因此 ， 应 该 将 动态 内 容 和 静态 资源 分 离 ， 一 般 应 该 将 静态 资源 放 在 CDN 
上 ， 如 下 图 所 示 。 


| 
用 户 请 求 


静态 资源 


JS/CSS 5 | 


3.7 EERS 


TESEERML AS rh, FN Beit EH Sz RES m pen], Me SURE 
种 流 量 的 比例 能 达到 5:1， 甚 至 更 高 。 而 一 些 系 统 是 因为 爬虫 访问 量 太 大 
而 导致 服务 不 可 用 。 一 种 解决 办 法 是 通过 限 流 解决 ， 另 一 种 解决 办 法 是 
eee Mf PRUEIE fA Tit A A, KH 
MEREN 8 
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Nginx 
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最 简单 的 方法 是 使 用 Nginx， 可 以 这 样 配置 。 


set $flag 0; 

if (Shttp user agent ~* "spider") { 
set Sflag "1"; 

} 

if(Sflag = "0") { 
// 代 理 到 正常 集群 

} 

if ($flag = "1") { 
/ / RESTE E A BE 

} 


SE ERE Bal T OpenResty, AMXX E Huser-agentwiiz, xb ite— 
些 恶意 IP GEST IP] SORA BA) ， 将 它们 分 流 到 固定 分 组 ， 这 
种 情况 会 存在 一 定 程度 的 误杀 ， 因 为 公司 的 公 网 了 P 一 般 情况 下 是 同一 
个 ， 大 家 使 用 同一 个 公 网 出 口 卫 访问 网 站 ， 因 此 ， 可 以 考虑 IP+Cookie 的 
方式 ， 在 用 户 浏览 器 种 植 标识 用户 身份 的 唯一 Cookie。 访 问 服务 前 先 种 
植 Cookie， 访 问 服务 时 验证 该 Cookie， 如 果 没 有 或 者 不 正确 ， 则 可 以 考虑 
分 流 到 固定 分 组 ， 或 者 提示 输入 验证 码 后 访问 。 


3.8 ”热点 隔离 


秒杀 、 抢 购 属 于 非常 合适 的 热点 例子 ， 对 于 这 种 热 护 ， 是 能 提前 知道 
的 ， 所 以 可 以 将 秒杀 和 抢购 做 成 独立 系统 或 服务 进行 隔离 ， 从 而 保证 秘 
杀 / 抢 购 流 程 出 现 问题 时 不 影响 主流 程 。 


还 存在 一 些 热点 ， 可 能 是 因为 价格 或 突 发 事件 引起 的 。 对 于 读 热 点 ， 笔 
者 使 用 多 级 缓存 来 摘 定 ， 而 写 热点 我 们 一 般 通 过 缓存 + 队列 模式 削 峰 ， 可 
以 参考 “前 端 交 易 型 系统 设计 原则 ”。 


3.9 ”资源 隔离 


最 第 见 的 资源 ， 如 磁盘 、CPU、 网 络 ， 这 些 宝贵 的 资源 ， 都 会 存在 竞争 
问题 。 


在 “构建 需求 响应 式 亿 级 商品 详情 页 * 中 ， 我 们 使 用 JIMDB 数 据 同步 时 要 
dump 数 据 ，SSD 盘 容量 用 了 50% 以 上 ，dump 到 同一 块 磁盘 时 遇 到 了 容量 
不 足 的 问题 ， 我 们 通过 单独 挂 一 块 SAS 盘 来 专门 同步 数据 。 还 有 ， 使 用 
Docker 容 器 时 ， 有 的 容器 写 磁盘 非常 频繁 ， 因 此 ， 要 考虑 为 不 同 的 容器 
挂 载 不 同 的 磁盘 。 


4 
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默认 CPU 的 调度 策略 在 一 些 奶 求 极 致 性 能 的 场景 下 可 能 并 不 太 适 合 ， 我 
们 和 希望 通过 绑 定 CPU 到 特定 进程 来 提升 性 能 。 当 一 台 机 顺 局 动 很 多 Redis 
实例 时 ， 将 CPU 通过 taskset 绑 定 到 Redis 实 例 上 可 以 提升 一 些 性 能 。 还 
有 ，Nginx 提 供 了 worker_processes 7llworker. cpu. affinity2 48 XE CPU ° 如 
系统 网 络 应 用 比较 党 忙 ， 可 以 考虑 将 网 卡 IRQ 绑 定 到 指定 的 CPU 来 提升 系 
统 处 理 中 断 的 能 力 ， 从 而 提升 整体 性 能 。 


可 以 通过 cat /proc/interrups Æ d F it UL. m3 
过 /proc/irg/N/smp. affinity 手动 设置 中 断 要 绑 定 的 CPU。 或 者 开 
irqgbalance 优 化 中 断 分 配 ， 将 中 断 均 匀 地 分 发 给 CPU。 


还 有 如 大 数据 计算 集群 、 数 据 库 集群 应 该 和 应 用 集群 隔离 到 不 同 的 机 架 
或 机 房 ， 实 现 网 络 的 隔离 ;因为 大 数据 计算 或 数据 库 同 步 时 会 占用 比较 
大 的 网 络 带宽 ， 可 能 会 拥塞 网 络 导致 应 用 啊 应 变 慢 。 


还 有 一 些 其 他 类 似 的 隔离 术 ， 如 环境 隔离 (测试 环境 、 预 发 布 环境 / 灰 度 
环境 、 正 式 环境 ) ` EWEA (真实 数据 、 压 测 数 据 隔 离 》 、AB 测 试 
(为 不 同 的 用 户 提供 不 同 版 本 的 服务 ) 、 缓 存 隔离 (有 些 系 统 混 用 绥 
存 ， 而 有 些 系统 会 扔 大 字 节 值 到 Redis， 造 成 Redis 慢 查询 ) 、 查 询 隔 离 
(人 简单、 批量 、 复 洒 条 件 查 询 分 别 路 由 到 不 同 的 集群 ， 等 。 通 过 隔离 ， 

可 以 将 风险 降 到 最 低 ， 将 性 能 提升 至 最 优 。 


3.10 ”使 用 Hystrix 实 现 隔离 
3.10.1 Hystrix 简 介 


Hystrix 征 Netflix 开 源 的 一 款 针 对 分 布 式 系统 的 延迟 和 容错 库 ， 目 的 是 用 来 
隅 离 分 布 式 服务 故障 。 它 提供 线程 和 信和 号 量 隔 离 ， 以 减少 不 同 服务 之 间 
人 质 源 竞争 带 来 的 相互 影响 ， 提 供 优 雅 降级 机 制 ， 提供 和 熔断 机 制 使 得 服务 
可 以 快速 失败 ， 而 不 是 一 直 阻 塞 等 待 服务 啊 应 ， 并 能 从 中 快速 恢复 。 
Hystrix 通 过 这 些 机 制 来 阻止 级 联 失 败 并 保证 系统 弹性 、 可 用 。 下 图 是 一 
个 典型 的 分 布 式 服务 实现 。 
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首先 ， 当 大 多 数 人 在 使 用 Tomcat 时 ， 多 个 HTTP 服 务 会 共 译 一 个 线程 池 ， 
假设 其 中 一 个 HTTP 服 务 访问 的 数据 库 啊 应 非常 慢 ， 这 将 造成 服务 啊 应 时 
间 延 迟 增加 ， 大 多 数 线程 阻塞 等 竺 数据 响应 返回 ， 导 致 整个 Tomcat 线 程 
池 都 被 该 服务 占用 ， 甚 至 拖 震 整个 Tomcat。 因 此 ， 如 有 果 我 们 能 把 不 同 
HTTP 服 务 隔离 到 不 同 的 线程 池 ， 则 某 个 HTTP 服 务 的 线程 池 满 了 也 不 会 
Ee Relea ea USE 


使 用 线程 隔离 或 信号 隅 离 的 目的 是 为 不 同 的 服务 分 配 一 定 的 资源 ， 当 目 
己 的 资源 用 完 ， 直 接 返 回 失 败 而 不 是 占用 别人 的 资源 。 


同 理 ， 如 “HTTP 服 务 1” 和 “HTTP 服 务 2” 要 分 别 访 问 远 程 的 “分 布 式 服务 
A” 和 “分 布 式 服务 B”， 假 设 它们 共享 线程 池 ， 那 么 其 中 一 个 服务 在 出 现 问 
题 时 也 会 影响 到 另 一 个 服务 ， 因 此 ， 我 们 需要 进行 访问 隔离 ， 可 以 通过 
Hystrix 的 线程 池 隔 离 或 信号 量 隔 离 来 实现 。 


其 次 ，“ 分 布 式 服务 B” 依 赖 了 “分 布 式 服务 D" 和 “分 布 式 服务 E”>， 其 中 “分 
布 式 服务 D” 是 一 个 可 降级 的 服务 ， 意 思 是 出 现 故 隘 时 (如 超时 、 网 络 故 
障 ) 可 以 暂时 屏蔽 掉 或 者 返回 缓存 及 数据， 如 访问 商品 详情 页 时 ， 可 以 
暂时 屏蔽 掉 上 边 的 商家 信息 ， 不 会 影响 用 户 下 单 流程 。 


当 我 们 依赖 的 服务 访问 超时 时 ， 要 提供 降级 策略 。 比 如 ， 返 回 托 故 数据 
阻止 级 联 故障 。 当 因为 一 些 故 障 (如 网 络 故 障 ) 使 得 服务 可 用 率 下 降 
时 ， 要 能 及 时 熔断 ， 一 是 快速 失败 ， 二 是 可 以 保护 远程 分 布 式 服务 。 

到 此 我 们 大 体 了 解 了 Hystrix 是 用 来 解决 什么 问题 的 。 


1. 限 制 调用 分 布 式 服务 的 资源 使 用 ， 共 一 个 调用 的 服务 出 现 问 题 不 会 影响 
其 他 服务 调用 ， 通 过 线程 池 隔 离 和 信号 量 隔 离 实现 。 


2.Hystrix 提 供 了 优雅 降级 机 制 : 超时 降级 、 资 源 不 足 时 (线程 或 信号 量 ) 
降级 ， 降 级 后 可 以 配合 降级 接口 返回 托 底 数据 。 


3.Hystrix 也 提供 了 熔断 器 实现 ， 当 失败 率 达到 冰 值 自动 触发 降级 〈 如 因 网 
络 故障 /超时 造成 的 失败 率 高 ) ， 熔 断 器 触发 的 快速 失败 会 进行 快速 恢 
LE 

4. 还 提供 了 请 求 缓存 、 请 求 合 并 实现 。 


接 下 来 ， 我 们 来 看 一 下 如 何 使 用 Hystrix， 本 书 使 用 的 版 本 是 Hystrix- 
1.5.6° 


3.10.2 ”隔离 示例 
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为 不 同 的 HTTP 服务 设置 不 同 的 线程 池 ， 为 不 同 的 分 布 式 服 务 调用 设置 不 
同 的 线程 池 。 


假设 我 们 现在 要 调用 一 个 获取 库存 服务 ， 通 过 封装 一 个 命令 
GetStockService Command 来 实现 。 
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public class GetStockServiceCommand extends HystrixCommand<String> { 
private StockService stockService; 
public GetStockServiceCommand() ( 
super(setter()); 
) 
private static Setter setter() { 
// 服 务 分 组 
HystrixCommandGroupKey groupKey = 
HystrixCommandGroupKey.Factory. asKey("stock"); 
/ /服务 标识 
HystrixCommandKey commandKey = 
HystrixCommandKey.Factory.asKey("getStock"); 
// 线 程 池 名 称 
HystrixThreadPoolKey threadPoolKey = 
HystrixThreadPoolKey.Factory.asKey("stock-pool"); 
// 线 程 池 配置 
HystrixThreadPoolProperties.Setter threadPoolProperties = 
HystrixThreadPoolProperties.Setter() 
.withCoreSize (10) 
.withKeepAliveTimeMinutes (5) 
.withMaxQueueSize (Integer.MAX VALUE) 
.WithQueueSizeRejectionThreshold (10000); 


// 命 令 属性 配置 
HystrixCommandProperties.Setter commandProperties = 
HystrixCommandProperties.Setter() 
.wWithExecutionIsolationStrategy (HystrixCommandProp 


erties.ExecutionIsolationStrategy. THREAD) ; 


return HystrixCommand.Setter 
. withGroupKey (groupKey) 
.andCommandKey (commandKey) 
.andThreadPoolKey (threadPoolKey) 
.andThreadPoolPropertiesDefaults (threadPoolProperties) 
.andCommandPropertiesDefaults (commandProperties); 
) 
@Override 
protected String run() throws Exception { 
return stockService.getStock(); 


几 个 重要 组 件 如 下 。 


HystrixCommandGroupKey: 配置 全 局 唯一 标识 服务 分 组 的 名 称 ， 比 
如 ， 库 存 系统 就 是 一 个 服务 分 组 。 当 我 们 监控 时 ， 相 同 分 组 的 服务 会 聚 
合 在 一 起 ， 必 填 选 项 。 


HystrixCommandKey: 配置 全 局 唯一 标识 服务 的 名 称 ， 比 如 ， 库 存 系统 
有 一 个 获取 库存 服务 ， 那 么 就 可 以 为 这 个 服务 起 一 个 名 字 来 唯一 识别 该 
服务 ， 如 有 果 不 配 置 ， 则 默认 是 简单 类 名 。 


HystrixThreadPoolKey: 配置 全 局 唯一 标识 线程 池 的 名 称 ， 相 同 线程 池 
名 称 的 线程 池 是 同一 个 ， 如 果 不 配 置 ， 则 默认 是 分 组 名 ， 此 名 字 也 是 线 
程 池 中 线程 名 字 的 前 级 。 


HystrixThreadPoolProperties: 配置 线程 池 参 数 ，coreSize 配 置 核心 线程 
池 大 小 和 线程 池 最 大 大 小 ，keepAliveTimeMinutes 是 线程 池 中 空 内 线程 生 
存 时 间 〈 如 果 不 进 行动 态 配置 ， 那 么 是 没有 任何 作用 的 ) ， 
maxQueueSize 配 置 线程 池 队 列 最 大 大 小 ，queueSizeRejectionThreshold 限 
定 当 前 队列 大 小 ， 即 实际 队列 大 小 由 这 个 参数 决定 ， 通 过 改变 
queueSizeRejectionThreshold 可 以 实现 动态 队列 大 小 调整 。 


HystrixCommandProperties : 配置 该 命令 的 一 些 参 数 ， 
executionIsolationStrategy 配 置 执行 隔离 策略 ， 默认 是 使 用 线程 隔离 ， 此 处 
我 们 配置 为 THREAD， 即 线程 池 隔 离 。 


此 处 可 以 粗 粒 度 实 现 隔离 ， 也 可 以 细 粒 度 实 现 隅 离 ， 如 下 所 示 。 


服务 分 组 + 线程 池 :， 粗 粒度 实现 ， 一 个 服务 分 组 /系统 配置 一 个 隅 离线 程 
池 即 可 ， 不 配置 线程 池 和 名称 或 者 相同 分 组 的 线程 池 名 称 配 置 为 一 样 。 


服务 分 组 + 服务 + 线程 池 :， 细 粒度 实现 ， 一 个 服务 分 组 中 的 每 一 个 服务 配 
置 一 个 隔离 线程 池 ， 为 不 同 的 命令 实现 配置 不 同 的 线程 池 名 称 即 可 。 


混合 实现 ， 一 个 服务 分 组 配置 一 个 隔离 线程 池 ， 然 后 对 重要 服务 单独 设 
置 隔离 线程 池 。 


如 上 配置 是 在 应 用 局 动 时 就 配置 好 了 ， 在 实际 运行 过 程 中 ， 我 们 可 能 有 
时 调整 其 中 一 些 参数 ， 如 线程 池 大 小 、 队 列 大 小 ， 此 时 ， 可 以 使 用 如 下 
方式 进行 动态 配置 。 


String dynamicQueueSizeRejectionThreshold =  "hystrix.threadpool." + 
"stock-pool" + ".queueSizeRejection Threshold"; 


Configuration configuration = ConfigurationManager.getConfigInstance (); 
configuration.setProperty(dynamicQueueSizeRejectionThreshold, 100); 
如 果 是 改变 线程 池 配 置 ， 则 是 "hystrix.threadpool." + threadPoolKey + 


propertyName; 如 果 是 改变 命令 属性 配置 ， 则 是 "hystrix.command." + 
commandKey + propertyName ° 


接 下 来 就 可 以 通过 如 下 方式 创建 命令 。 


GetStockServiceCommand command = new GetStockServiceCommand(new 
StockService()); 


然后 通过 如 下 方式 同步 调用 。 
String result = command.execute(); 


或 者 返回 Future 从 而 实现 异步 调用 。 


Future<String> future = command.queue(); 
或 者 配合 RxJava 实 现 啊 应 式 编程 。 


Observable«String» observe = command.observe(); 

observe.asObservable().subscribe((result) -> { 
System.out.println(result); 

)); 


在 应 用 Hystrix 时 ， 首 先 需要 把 服务 封装 成 HystrixCommand， 即 命令 模式 
实现 ， 然 后 就 可 以 通过 同步 /异步 /响应 式 模 式 来 调用 服务 。 


信和 号 量 隅 离 通过 如 下 配置 印 可 。 


HystrixCommandProperties.Setter commandProperties = 


HystrixCommandProperties.Setter() 
.withExecutionIsolationStrategy (HystrixCommandProperties.Execut 
ionIsolationStrategy. SEMAPHORE) 
.withExecutionIsolationSemaphoreMaxConcurrentRequests (50); 


信和 号 量 隔 离 只 是 限制 了 总 的 并 发 数 ， 服 务 使 用 主线 程 进行 同步 调用 ， 即 
没有 线程 池 。 因 此 ， 如 果 只 是 想 限 制 某 个 服务 的 总 并 发 调用 量 或 者 调用 
的 服务 不 涉及 远程 调用 的 话 ， 可 以 使 用 轻 量 级 的 信和 号 量 来 实现 。 


GetStockServiceCommand 不 是 单 例 ， 不 能 重用 ， 必 须 每 次 使 用 创建 一 
个 。 如 果 觉 得 Hystrix 太 麻烦 或 者 太 重 ， 则 可 以 参考 Hystrix 思 路 设计 自己 
的 组 件 。 


3.11 基于 Servlet 3 实现 请 求 隔离 


在 京东 商品 详情 页 系统 《后 端 数据 源 ) 及 商品 详情 页 统一 服务 系统 (页 
面 中 异步 加 载 的 很 多 服务 ， 如 库存 服务 、 图 书 相 关 服 务 、 延 保 服 务 等 ) 
中 ， 我 们 使 用 了 Servlet 3 请 求 异步 化 模型 ， 本 文 总 结 了 Servlet 3 请 求 异 步 
化 的 一 些 经 验 。 

我 们 将 从 如 下 几 点 来 了 解 Servlet 3 异步 化 : 为 什么 实现 请 求 异步 化 需要 使 
Fi Servlet 3、 请 求 异步 化 后 得 到 的 好 处 是 什么 、 如 何 使 用 Servlet 3 异步 
化 ， 以 及 一 些 Servlet 3 异步 化 压 测 数据 。 


Tomcat 在 收 到 HTTP 请 求 后 会 按照 如 下 流程 处 理 请 求 。 


3. 最 后 通过 HttpServletResponse 写 出 响应 。 


在 Servlet 2.x 规 范 中 ， 所 有 这 些 处 理 都 是 同步 进行 的 ， 也 就 是 说 必须 在 一 
个 线程 中 完成 从 接收 请 求 、 业务 处 理 到 啊 应 。 


此 处 以 Tomcat 6 为 例 。Tomcat 6 没有 实现 Servlet 3 规范 ， 它 在 处 理 请 求 时 
是 通过 如 下 方式 实现 的 。 


org.apache.catalina.connector.CoyoteAdapter#service 

// Recycle the wrapper request and response 

if (!comet) { 
request.recycle(); 
response.recycle(); 

} else { 
// Clear converters so that the minimum amount of memory 
// is used by this processor 
request.clearEncoders(); 
response.clearEncoders(); 


} 


ETS RAD RAY, Sele) PET RAYA, Het ee a HART + MLSS Sch BE 
和 响应 必须 在 一 个 线程 内 完成 ， 不 能 跨越 线程 界限 。 


这 也 就 说 明了 必须 使 用 实现 了 Servlet 3 规范 的 容器 进行 处 理 ， 如 Tomcat 
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请 求 异 步 化 后 得 到 的 好 处 如 下 所 示 。 


- 基于 NIO 能 处 理 更 高 的 并 发 连接 数 ， 我 们 使 用 JDK 7 配合 Tomcat 7， 压 测 
得 到 不 错 的 性 能 表现 o 


. 请 求解 析 和 业务 处 理 线程 池 分 离 。 

. 根据 业务 重要 性 对 业务 分 级 ， 并 分 级 线程 池 。 

.对 业务 线程 池 进行 监控 、 运 维 、 降 级 等 处 理 。 

3.11.1 请 求解 析 和 业务 处 理 线程 池 分 离 


在 引入 Servlet 3 之 前 我 们 的 线程 模型 是 如 下 样子 。 


T t 

线程 1 | 业务 处 理 | | 生成 响应 
e T 1! t 

一 HTTP 请 求 站 线程 池 spiny | 业务 处 理 | | 生成 响应 


Tomcat 


整个 请 求解 机 、 业 务 处 理 、 生 成 啊 应 都 是 由 Tomcat 线 程 池 进 行 处 理 的 ， 
而 且 都 是 在 一 个 线程 中 处 理 ， 不 能 分 离线 程 处 理 ， 比 如 接收 到 请 求 后 交 
给 其 他 线程 处 理 ， 则 不 能 灵活 定义 业务 处 理 模型 。 


引入 Servlet 3 之 后 ， 我 们 的 线程 模型 可 以 改造 为 如 下 样子 。 


lb 一 二 一 
FTT METUS 
_HTTp 请 求 >| Tomcat [请 求解 析 | > 。 业务 ”| 业务 业务 业务 处 理 | 生成 响应 
RD 单线 程 | 请 队列 线程 池 线程 》 | 业务 处 理 | | 生成 响应 
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此 处 可 以 看 到 请 求解 析 使 用 Tomcat 单 线程 ， 而 解析 完成 后 会 将 请 求 扔 到 
x d 由 业务 线程 池 进 行 处 理 ， 这 种 处 理 方 式 可 以 得 到 如 下 好 
.根据 业务 重要 性 对 业务 进行 分 级 ， 然 后 根据 分 级 定义 线程 池 。 

“ 可 以 拿 到 业务 线程 池 ， 可 以 进行 很 多 操作 ， 比 如 监控 、 降 级 等 。 


3.11.2 ”业务 线程 池 隔 离 

在 一 个 系统 的 发 展期 间 ， 我 们 一 般 把 很 多 服务 放 到 一 个 系统 中 进行 处 
理 ， 比 如 库存 服务 、 图 书 相关 服务 、 延 保 服务 等 ， 这 些 服务 中 ， 可 以 根 
据 其 重要 性 对 业务 分 级 别 和 做 一 些 限制 。 

.可 以 把 业务 分 为 核心 业务 级 别 和 非 核心 业务 级 别 。 


` 为 不 同 级 别 的 业务 定义 不 同 的 线程 池 ， 线 程 池 之 间 是 隔离 的 。 


根据 业务 量 定义 各 级 别 线程 池 大 小 。 
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此 时 ， 假 设 非 核心 业务 因为 数据 库 连 接 池 或 者 网 络 问题 引发 抖动 ， 造 成 
响应 时 间 过 长 ， 不 会 对 我 们 的 核心 业务 产生 影响 。 


3.11.3 ”业务 线程 池 监 控 / 运 维 / 降 级 


因为 业务 线程 池 从 Tomcat 中 分 离 出 来 ， 可 以 进行 线程 池 的 监控 ， Ee 
查看 当前 处 理 的 请 求 有 多 少 ， 是 否 到 了 人 负载 瓶 贷 ， 如 到 了 瓶 有 贷 可 以 进 
业务 报警 等 处 理 。 


查看 零 级 请 求 处 理 线程 FEB aei ~~ [aerol evel /asyacServ] et /backend/get 


级 请 求 处 理 线 ['corePoolSize: 128, poem olSize":1024, “poo! ouem de Urost Po olSize" :66, " activeCount" :0, “taskCount”: 102, “conpletedTaskCount” : 102, "keepAliveTineInSeconds":6 
一 级 请 求 h nE 0, " irQueueSize” :0, " renainingCa] pacity” 22048, “asyncTim :3) 


NRERIN SH, 


http:/, /zeroLevel/asyncServlet/backend/get' 
l'corePoolSize" : 128, " naximunPoolSize" :1024, “poolSize": 128, “largestPoolSize" : 128,“ activeCount": 2, “taskCount": 6478641, “complet edTaskCount " :6478639, "keepAliveTimel 
nSeconds" : 60, “inQueueSize": 0,“ renainingCapacity" : 2048, " asyncTimeout“: 3} 


http:/, eroLevel /asyncSe: muet ckend/get?: 


{“corePoolSize" : 128, Um olSize":1024, “poo! oolSize": 128, "largestPoolSizi e^ :128, " activeCount" :2, “taskCount”: 8993881, “complet edTaskCount " :8993879, "keepAliveTimel 
nSeconds" : 60, "inQueueSize" : 0, " renainingCapacity': 12048," asyncTimeout“: 3} 


bttp: // /zerolevel/asyncServlet/backend/get' 
{"corePoolSize" : 128, " naximumPoolSize" :1024, "poolSize":128, "largestPoolSize" : 128, " activeCount" : 3, " taskCount ^: 5221100, “complet edTaskCount " :5221097, "keepAliveTimel 
See ands" :60,” “inque ueSize“:0,”remainingCapacity” : 2048, " asyncTimeout “: 3} 


上 图 是 一 个 简陋 的 监控 图 ， 可 实时 查看 到 当前 处 理 情况 ， 正 在 处 理 的 任 
务 有 多 少 ， 队 列 中 等 每 的 任务 有 多 少 ， 可 以 根据 这 些 数据 进行 监控 和 预 


[zz 


Ip: 

17. 28 

17. 10 

17. 11 

17. 12 

17. 13 

17. 45 

17. 46 

17. 37 

17; 39 M 


thread pool core size( 初 始 大 小 ) : 428 

thread pool max size (最 大 大 小 ) : 1024 

thread pool keep alive timeout 【线程 空 异 超时 时 间 / 秒 ) : 60 
request async timeout 【请 求 处 理 超 时 时 间 / 秒 ) : 3 


修改 线程 池 | | | 清空 线程 池 
现在 ， 对 业务 线程 池 进行 扩容 ， 或 者 业务 出 问题 时 立即 清空 线程 池 防止 
容器 崩溃 等 问题 ;而 不 需要 进行 容器 重启 。 容 器 重启 需要 耗费 数 十 秒 其 
至 数 几 十 秒 ， 而 且 启 动 后 会 有 预 热 问 题 ， 造 成 业务 产生 拌 动 。 


如 采 发 现 请 求 处 理 不 过 来 ， 负 载 比 较 高 ， 那 么 最 简单 的 办 法 吏 是 直接 清 
空 线程 池 ， 将 老 请 求 拒 绝 挥 ， 避 免 出 现 雪 月 效应 。 


因为 业务 队列 和 业务 线程 江都 是 自己 的 ， 可 以 对 这 些 基础 组 件 做 很 多 处 


PE. 定制 业务 队列 ， 按 照 用 户 级 别 对 用 户 请 求 排序 ， 让 高 级 别 用 户 得 到 
更 高 优先 级 的 业务 处 理 。 


3.11.4 ”如 何 使 用 Servlet 3 异步 化 


对 于 Servlet 3 的 使 用 ， 可 以 参考 笔者 博客 中 的 文章 《Servlet 3.1 规 范 (最 
终 版 ) 中 文 版 》 和 Servlet 3.1 学 习 示 例 ， 笔 者 项 目 里 的 实现 比较 简单 。 


1. 接 收 请 求 
通过 一 级 业务 线程 池 接 收 请 求 ， 并 提交 业务 处 理 到 该 线程 池 。 


@RequestMapping ("/book") 

public void getBook( 
HttpServletRequest request, 
GRequestParam(value-"skuId") final Long skuld, 
@RequestParam(value="cat1") final Integer catl, 
@RequestParam(value="cat2") final Integer cat2) throws Exception { 
oneLevelAsyncContext.submitFuture (request, 

() -> bookService.getBook (skuId, catl, cat2)); 


2. 业 务 线程 池 封 装 


public void submitFuture( 
final HttpServletRequest req, final Callable «Object» task) ( 
final String uri = req.getRequestURI (); 
final Map<String, String[]> params = req.getParameterMap(); 
final AsyncContext asyncContext = req.startAsync(); // 开 启 异步 上 下 文 
asyncContext.getRequest().setAttribute("uri", uri); 
asyncContext.getRequest().setAttribute("params", params); 
asyncContext.setTimeout(asyncTimeoutInSeconds * 1000); 
if(asyncListener !- null) { 
asyncContext.addListener (asyncListener); 
) 
executor.submit (new CanceledCallable(asyncContext) ( / 棍 交 任务 给 业务 线程 池 
GOverride 
public Object call() throws Exception { 
Object o = task.call(); // 业 务 处 理 调用 
if(o == null) { 
callback(asyncContext, o, uri, params); // 业 务 完成 后 ， 响 应 处 理 
} 
if(o instanceof CompletableFuture) { 
CompletableFuture<Object> future = 
(CompletableFuture <Object>) 0; 
future.thenAccept (resultObject -> 
callback (asyncContext, resultObject, uri, params) ) 
.exceptionally(e -> { 
callback(asyncContext, "", uri, params); 
return null; 
BE 


} else if(o instanceof String) { 
callback(asyncContext, o, uri, params); 


) 


return null; 


)); 
} 
private void callback(AsyncContext asyncContext, Object result, 
String uri, Map<String, String[]> params) { 
HttpServletResponse resp = 
(HttpServletResponse) asyncContext. getResponse(); 
try { 
if(result instanceof String) { 
write(resp, (String) result) ; 
} else { 
write(resp, JSONUtils.toJSON (result) ); 
} 
} catch (Throwable e) { 
resp.setStatus (HttpServletResponse.SC INTERNAL SERVER ERROR); 
// 程序 内 部 错误 
try { 
LOG.error("get info error, uri : {}, params : {}", 
uri, JSONUtils.toJSON(params), e); 
} catch (Exception ex) { 
} 
) finally ( 
asyncContext.complete(); 


) 


3. 线 程 池 的 初始 化 


@Override 
public void afterPropertiesSet() throws Exception { 


String[] poolSizes = poolSize.split("-"); 

// 初 始 线程 池 大 小 

int corePoolSize = Integer.valueOf(poolSizes[0]); 

// 最 大 线程 池 大 小 

int maximumPoolSize = Integer.valueOf(poolSizes[1]); 


queue = new LinkedBlockingDeque<Runnable>(queueCapacity) ; 
executor = new ThreadPoolExecutor ( 
corePoolSize, maximumPoolSize, 
keepAliveTimeInSeconds, TimeUnit.SECONDS, 


queue); 


executor.allowCoreThreadTimeOut (true); 
executor.setRejectedExecutionHandler( 
new RejectedExecutionHandler() ( 
GOverride 
public void rejectedExecution( 
Runnable r, ThreadPoolExecutor executor) { 
if(r instanceof CanceledCallable) { 


CanceledCallable cc = ((CanceledCallable) r); 
AsyncContext asyncContext = cc.asyncContext; 
if(asyncContext != null) { 
try í 
ServletRequest req = asyncContext.getRequest (); 
String uri = (String) req.getAttribute ("uri") ; 


Map params = (Map) req.getAttribute ("params"); 
LOG.error ("async requestrejected, wi: {}, grams 
{}", uri, JSONUtils.toJSON(params)); 
} catch (Exception e) {} 
try { 
HttpServletResponse resp = 
(HttpServletResponse) asyncContext.getResponse(); 
resp.setStatus( 
HttpServletResponse.SC INTERNAL SERVER ERROR); 
) finally { 
asyncContext.complete(); 


}); 


if(asyncListener == null) { 
asyncListener = new AsyncListener() { 
@Override 
public void onComplete(AsyncEvent event) throws IOException { 
} 
@Override 
public void onTimeout (AsyncEvent event) throws IOException { 
AsyncContext asyncContext = event.getAsyncContext (); 
try { 
ServletRequest req = asyncContext.getRequest () ; 
String uri = (String) req.getAttribute ("uri") ; 
Map params = (Map) req.getAttribute ("params") ; 
LOG.error("async request timout, uri :{}, params :{}", 


uri, JSONUtils.toJSON(params)); 
} catch (Exception e) {} 
try { 
HttpServletResponse resp = 
(HttpServletResponse) asyncContext.getResponse(); 
resp.setStatus( 
HttpServletResponse.SC INTERNAL SERVER ERROR); 
) finally { 
asyncContext.complete (); 


QOverride 
public void onError(AsyncEvent event) throws IOException { 
// 省 略 onError 代码 ， 与 onTimeout 类 似 


@Override 
public void onStartAsync(AsyncEvent event) 
throws IOException { 


} 
4. 业 务 处 理 
执行 bookService.getBook(skuld, cat1, cat2) 进 行业 务 处 理 。 
5. 返 回响 应 
在 之 前 封装 的 异步 线程 池上 下 文中 直接 返回 。 
6.Tomcat server.xml 的 配置 


«Connector port-"1601" asyncTimeout-"10000" 
acceptCount="10240" maxConnections="10240" acceptorThreadCount="1" 
minSpareThreads="1" maxThreads="1" redirectPort="8443" 
processorCache="1024" URIEncoding-"UTF-8" 
protocol-"org.apache.coyote.httpll.Httpll1NioProtocol" 
enableLookups-"false"/» 


此 处 可 以 看 到 ，Tomcat 线 程 池 配 置 了 maxThreads=1， 即 一 个 线程 进行 请 
求解 析 。 


3.11.5 ”一些 Servlet 3 异步 化 压 测 数据 


压 测 机 器 基本 环境 : 32 核 CPU、32G 内 存 ; jdk1.7.0_71 + tomcat 7.0.57, 
服务 响应 时 间 在 20ms+， 使 用 最 简单 的 单个 URL 压 测 吞 吐 量 。 


1. 使 用 BIO 方式 压 测 

siege-3.0.7]# ./src/siege -c100 -t60s -b http://***.item.jd.com/981821 
Transactions: 279187 hits 

Availability: 100.00 % 

Elapsed time: 59.33 secs 

Data transferred: 1669.41 MB 

Response time: 0.02 secs 

Transaction rate: 4705.66 trans/sec 

Throughput: 28.14 MB/sec 

Concurrency: 99.91 

Successful transactions: 279187 

Failed transactions: 0 

Longest transaction: 1.04 

Shortest transaction: 0.00 

2. 使 用 Servlet 3 NIO 异 步 化 压 测 100 并 发 、60s 

siege-3.0.7]# ./src/siege -c100 -t60s -b http://***.item.jd.com/981821 


Transactions: 337998 hits 


Availability: 100.00 96 

Elapsed time: 59.09 secs 

Data transferred: 2021.07 MB 

Response time: 0.03 secs 

Transaction rate: 5720.05 trans/sec 

Throughput: 34.20 MB/sec 

Concurrency: 149.79 

Successful transactions: 337998 

Failed transactions: 0 

Longest transaction: 1.07 

Shortest transaction: 0.00 

3. 使 用 Servlet 3 NIO 异 步 化 压 测 600 并 发 、60s 
siege-3.0.7]# ./src/siege -c600 -t60s -b http://***.item.jd.com/981821 
Transactions: 370985 hits 

Availability: 100.00 % 

Elapsed time: 59.16 secs 

Data transferred: 2218.32 MB 

Response time: 0.10 secs 

Transaction rate: 6270.88 trans/sec 

Throughput: 37.50 MB/sec 


Concurrency: 598.31 


Successful transactions: 370985 
Failed transactions: 0 
Longest transaction: 1.32 


Shortest transaction: 0.00 


可 以 看 出 ， 异 步 化 之 后 否 吐 量 提 升 了 ， 但 啊 应 时 间 也 变 长 了 。 也 就 是 
异步 化 并 不 会 提升 响应 时 间 ， 但 会 增加 吞吐 量 和 我 们 需要 的 灵活 


通过 异步 化 我 们 不 会 获得 更 快 的 啊 应 时 间 ， 但 是 ， 我 们 获得 了 整体 否 吐 
量 和 我 们 需要 的 灵活 性 : 请 求解 机 和 业务 处 理 线程 池 分 离 ; 根据 业务 重 
要 性 对 业务 分 级 ， 并 分 级 线程 池 ; 对 业务 线程 池 进 行 监控 、 运 维 、 降 级 


等 处 理 。 
A 限 流 详解 


在 开发 高 并 发 系统 时 ， 有 很 多 手段 来 保护 系统 ， 如 缓存 、 降 级 和 限 流 
等 。 缓 存 目的 是 提升 系统 访问 速度 和 增 大 系统 处 理 能 力 ， 可 谓 是 抗 高 并 
发 流量 的 银 弹 。 而 降级 是 当 服务 出 问题 或 者 影响 到 核心 流程 的 性 能 ， 需 
要 暂 时 屏蔽 掉 ， 竺 高 峰 过 去 或 者 问题 解决 后 再 打开 的 场景 。 而 有 些 场 景 
并 不 能 用 缓存 和 降级 来 解决 ， 比 如 稀缺 资源 (秒杀 、 抢 购 ) 、 写 服务 

(如 评论 、 下 单 ) 、 频 繁 的 复杂 查询 (评论 的 最 后 儿 页 ) 等 。 因 此 ， 需 
有 一 种 手段 来 限制 这 些 场景 下 的 并 发 /请 求 量 ， 这 种 手段 就 是 限 流 。 


限 流 的 目的 是 通过 对 并 发 访问 /请 求 进行 限 速 或 者 一 个 时 间 窗 口内 的 请 求 
进行 限 速 来 保护 系统 ， 一 旦 达到 限制 速率 则 可 以 拒绝 服务 (定向 到 错误 
页 或 告知 资源 没有 了 ) 、 排 队 或 等 待 〈 比 如 秒杀 、 评 论 、 下 单 ) 、 降 级 

(返回 兜 底数 据 或 默认 数据 ， 如 商品 详情 页 库存 默认 有 货 ) 。 在 压 测 时 
我 们 能 找 出 每 个 系统 的 处 理 峰值 ， 然 后 通过 设 定 峰 值 阐 值 ， 来 防止 当 系 
统 过 载 时 ， 通 过 拒绝 处 理 过 载 的 请 求 来 保障 系统 可 用 。 另 外 ， 也 应 根据 
系统 的 吞吐 量 、 员 应 时 间 、 可 用 率 来 动态 调整 限 流 国 值 。 


一 般 开 发 高 并 发 系统 常见 的 限 流 有 : 限制 总 并 发 数 (比如 数据 库 连 接 
池 、 线 程 池 ) 、 限 制 瞬时 并 发 数 (如 Nginx 的 limit_conn 模 块 ， 用 来 限制 瞬 
时 并 发 连接 数 )、 限 制 时 间 窗 口内 的 平均 速率 (如 Guava 的 RateLimiter ^ 
Nginx 的 limit_req 模 块 ， 用 来 限制 每 秒 的 平均 速率 ) ， 以 及 限制 远程 接口 


调用 速率 、 限 制 MQ 的 消费 速率 等 。 另 外 ， 还 可 以 根据 网 络 连 接 数 、 网 络 
流量 、CPU 或 内 存 负 载 等 来 限 流 。 


先 有 缓存 这 个 银 弹 ， 后 有 限 流 来 应 对 618、 双 11 高 并 发 流量 ， 在 处 理 高 并 
发 问题 上 可 以 说 是 如 虎 添 对， 不 用 担心 瞬间 流量 导致 系统 挂 掉 或 雪 裔 ， 
最 终 做 到 有 损 服务 而 不 是 不 服务 。 限 流 需 要 评估 好 ， 不 可 乱用 ， 否 则 正 
党 流量 会 出 现 一 些 奇怪 的 问题 ， 而 导致 用 户 抱 怨 。 

在 实际 应 用 时 ， 也 不 要 太 纠 结算 法 问题 ， 因 为 一 些 限 流 算法 实现 是 一 样 
的 ， 只 是 描述 不 一 样 。 上 有 具体 使 用 哪 种 限 流 技术 ， 还 是 要 根据 实际 场景 来 
选择 ， 不 要 一 味 去 找 最 住 模 式 ， 白 猫 黑 猫 能 解决 问题 的 就 是 好 猫 。 

因 在 实际 工作 中 直到 过 许多 人 来 问 如 何 进 行 限 流 ， 因 此 本 文 会 详细 介绍 
各 种 限 流 手段 。 接 下 来 ， 我 们 从 限 流 算法 、 应 用 级 限 流 、 分 布 式 限 流 、 
接 入 层 限 流 来 详细 学 习 限 流 技术 手段 。 
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411 令 有 牌 桶 算法 


令 牌 桶 算法 ， 是 一 个 存放 固定 容量 令 牌 的 桶 ， 按 照 固定 速率 往 桶 里 添加 
令 牌 。 令 牌 桶 算法 的 描述 如 下 。 


-假设 限制 2s， 则 按照 500 蝇 秒 的 固定 速率 往 桶 中 交加 令 牌 。 
. 桶 中 最 多 存放 个 令 牌 ， 当 桶 满 时 ， 新 添加 的 令 牌 被 丢弃 或 拒绝 。 


当 一 个 n 个 字 市 大 小 的 数据 包 到 达 ， 将 从 桶 中 删除 n 个 令 牌 ， 接 着 数据 
包 被 发 送 到 网 络 上 。 


- 如 果 桶 中 的 令 牌 不 足 n 个 ， 则 不 会 删除 令 牌 ， 且 该 数据 包 将 被 限 流 (要 
LEF, BATA KS) ° 


令 牌 桶 

1、 限 速 10r/s 
则 按照 100 毫 秒 固定 速率 填 7 
o p WE jg 


2、 请 求 一 > 
请 求 的 速率 可 以 突 发 

并 且 令 牌 桶 允许 这 种 突 发 
5、 今 牌 不 足 则 拒绝 请 求 


、 处 理 请 求 一 > 


4.1.2” 漏 桶 算法 


漏 桶 作为 计量 工具 (The Leaky Bucket Algorithm as a Meter) 时 ， 可 以 用 
于 流量 整形 (Traffic Shaping) 和 流量 控制 (Traffic Policing) ， 漏 桶 算法 
的 描述 如 下 。 

一 个 固定 容量 的 漏 桶 ， 按 照常 量 固定 速率 流出 水 滴 。 

如 有 果 桶 是 空 的 ， 则 不 需 流出 水 滴 。 

可 以 以 任意 速率 流入 水 滴 到 漏 桶 。 


如 果 流 入 水 滴 超 出 了 桶 的 容量 ， 则 流入 的 水 滴 洪 出 了 (被 丢弃 ) ， 而 漏 
桶 容量 是 不 变 的 。 


iW 


s 
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1、 流 入 水 滴 
流入 速率 任意 


ô 3、 按 照常 量 速率 
流出 水 滴 


令 牌 桶 和 漏 桶 算法 对 比如 下 。 


. 令 牌 桶 是 按照 固定 速率 往 桶 中 添加 令 牌 ， 请 求 是 否 被 处 理 需要 看 桶 中 令 
牌 是 否 足够 ， 当 令 牌 数 减 为 零 时 ， 则 拒绝 新 的 请 求 。 


漏 桶 则 是 按照 常量 固定 速率 流出 请 求 ， 流 入 请 求 速率 任意 ， 当 流入 的 请 
求 数 累积 到 漏 桶 容量 时 ， 则 新 流入 的 请 求 被 拒绝 。 


- 令 牌 桶 限制 的 是 平均 流入 速率 〈 人 允许 突 发 请 求 ， 只 要 有 令 牌 就 可 以 处 
理 ， 支 持 一 次 拿 3 个 令 牌 或 4 个 令 牌 )， 并 人 允许 一 定 程 度 的 突 发 流量 。 

- 漏 桶 限制 的 是 常量 流出 速率 〈 即 流出 速率 是 一 个 固定 常量 值 ， 比 如 都 是 
1 的 速率 流出 ， 而 不 能 一 次 是 1， 下 次 又 是 2) ， 从 而 平滑 突 发 流入 速率 。 
令 牌 桶 允许 一 定 程度 的 突 发 ， 而 漏 彬 主要 目的 是 平滑 流入 速率 。 

- 两 个 算法 实现 可 以 一 样 ， 但 是 方向 是 相反 的 ， 对 于 相同 的 参数 得 到 的 限 
流 效果 是 一 样 的 。 


另外 ， 有 时 我 们 还 使 用 计数 船 来 进行 限 流 ， 主 要 用 来 限制 总 并 发 数 ， 比 
如 数据 库 连接 池 大 小 、 线 程 池 大 小 、 秒 杀 并 发 数 都 是 计数 右 的 用 法 。 只 
要 全 局 总 请 求 数 或 者 一 定时 间 段 的 总 请 求 数 达 到 设 定 阐 值 ， 则 进行 限 
流 。 这 古 一 种 简单 粗暴 的 总 数量 限 流 ， 而 不 是 平均 速率 限 流 。 


到 此 基本 的 算法 束 介 绍 完了 ， 接 下 来 我 们 首先 看 看 应 用 级 限 流 。 


4.2 ”应 用 级 限 流 


4.2.1 限 流 总 并 发 /连接 /请 求 数 


对 于 一 个 应 用 系统 来 说 ,一定 会 有 极限 并 发 /请 求 数 ， 即 总 有 一 个 
TPS/QPS 靖 值 ， 如 果 超 了 靖 值 ， 则 系统 束 会 不 啊 应 用 户 请 求 或 响应 得 非常 
慢 ， 因 此 我 们 最 好 进行 过 载 保护 ， 以 防止 大 量 请 求 涌 入 击 震 系 统 。 


如 果 你 使 用 过 Tomcat，Connector 其 中 一 种 配置 中 有 如 下 几 个 参数 。 


-acceptCount: ”如 果 Tomcat 的 线程 都 忙于 啊 应 ， 新 来 的 连接 会 进入 队列 
排队 ， 如 果 超 出 排队 大 小 ， 则 拒绝 连接 ; 


. maxConnections: 瞬时 最 大 连接 数 ， 超 出 的 会 排队 等 待 ; 


-maxThreads: Tomcat 能 局 动用 来 处 理 请 求 的 最 大 线程 数 ， 如 果 请 求 处 
理 量 一 直 远 远大 于 最 大 线程 数 ， 则 会 引起 啊 应 变 慢 甚至 会 伪 死 。 


详细 的 配置 请 参考 官方 文档 。 另 外 ， 如 MySQL (如 max_connections) ^ 
Redis (如 tcp- backlog) 都 会 有 类 似 的 限制 连接 数 的 配置 。 


4.2.2” 限 流 总 资源 数 


如 果 有 的 资源 是 稀缺 资源 (如 数据 库 连 接 、 线 程 ，， 而 且 可 能 有 多 个 系 
统 都 会 去 使 用 它 ， 那 么 需要 加 以 限制 。 可 以 使 用 池 化 技术 来 限制 总 资源 
数 ， 如 连接 池 、 线程 池 。 假 设 分 配给 每 个 应 用 的 数据 库 连 接 是 100， 那 么 
本 应 用 最 多 可 以 使 用 100 个 资源 ， 超 出 则 可 以 等 竺 或 者 抛 异 党 。 


4.2.3 ” 限 流 某 个 接口 的 总 并 发 /请 求 数 


如 果 接 口 可 能 会 有 突 发 访问 情况 ， 但 又 担心 访问 量 太 大 造成 月 沉 ， 如 抢 
购 业 务 ， 那 么 这 个 时 候 束 需要 限制 这 个 接口 的 总 并 发 /请 求 数 总 请 求 数 
了 。 因 为 粒度 比较 细 ， 可 以 为 每 个 接口 都 设置 相应 的 国 值 。 可 以 使 用 Java 
中 的 AtomicLong 或 者 Semaphore 进 行 限 流 ， 在 “隔离 术 ” 中 也 讲 到 了 ， 
Hystrix 在 信号 量 模式 下 也 使 用 Semaphore 限 制 某 个 接口 的 总 并 发 数 。 


try { 
if(atomic.incrementAndGet() > 限 流 数 ) ( 
// 拒 绝 请 求 
} 
// 处 理 请 求 
} finally { 
atomic.decrementAndGet () ; 


} 


这 种 方式 适合 对 可 降级 业务 或 者 需要 过 载 保护 的 服务 进行 限 流 ， 如 抢购 
业务 ， 超 出 限额 ， 要 么 让 用 户 排 队 ， 要 么 告诉 用 户 没 货 了 ， 这 对 用 户 来 
说 是 可 以 接受 的 。 而 一 些 开 放 平 台 也 会 限制 用 户 调用 某 个 接口 的 试用 请 
求 量 ， 这 时 就 可 以 用 这 种 计数 右 方 式 实现 。 这 种 方式 也 是 简单 粗暴 的 限 
流 ， 没 有 平滑 处 理 ， 需 要 根据 实际 情况 选择 使 用 。 


4.2.4” 限 流 某 个 接口 的 时 间 徐 请 求 数 


即 一 个 时 间 窗 口内 的 请 求 数 ， 如 想 限 制 某 个 接口 /服务 每 秒 /每 分 钟 /每 天 的 

请 求 数 /调用 量 。 如 一 些 基础 服务 会 被 很 多 其 他 系统 调用 ， 比 如 商品 详情 

页 服务 会 调用 基础 商品 服务 调用 ， 但 是 更 新 量 比较 大 有 可 能 将 基础 服务 

Hn. 这 时 ， 我 们 要 对 每 秒 /每 分 钟 的 调用 量 进行 限 速 ， 一 种 实现 方式 如 
ZR ° 


LoadingCache<Long, AtomicLong> counter = 
CacheBuilder.newBuilder() 
.expireAfterWrite(2, TimeUnit.SECONDS) 
.build(new CacheLoader<Long, AtomicLong>() { 
@Override 
public AtomicLong load(Long seconds) throws Exception { 


return new AtomicLong(0); 
} 
)); 
long limit = 1000; 
while(true) { 
// 得 到 当前 秒 
long currentSeconds = System.currentTimeMillis() / 1000; 
if(counter.get(currentSeconds).incrementAndGet() > limit) { 
System. out.println ("IRAT :" + currentSeconds) ; 
continue; 
} 
// 业 务 处 理 
} 


使 用 Guava 的 Cache 来 存储 计数 器 ， 过 期 时 间 设 置 为 2 秒 (保证 能 记录 1 秒 
内 的 计数 ) 。 然 后 ， 我 们 获取 当前 时 间 戳 ， 取 秒 数 来 作为 key 进 行 计 数 统 
计 和 限 流 ， 这 种 方式 简单 粗 壬 ， 但 应 付 刚 才 说 的 场景 够 用 了 。 


4.2.5 平滑 限 流 某 个 接口 的 请 求 数 


之 前 的 限 流 方式 都 不 能 很 好 地 应 对 突 发 请 求 ， 即 瞬间 请 求 可 能 都 被 允 
许 ， 从 而 导致 一 些 问 题 。 因此， 在 一 些 场 景 中 需要 对 突 发 请 求 进行 整 
形 ， 整 形 为 平均 速率 请 求 处 理 (比如 5r/s， 则 每 隔 200 写 秒 处 理 一 个 请 
AK, PETEK) 。 这 个 时 候 有 两 种 算法 满足 我 们 的 场景 : m ENNIUS 
桶 算法 。Guava 和 框架 提供 了 令 牌 桶 算法 实现 ， 可 直接 拿 来 使 用 。 


Guava RateLimiter 提供 的 令 牌 桶 算法 可 用 于 平滑 突 发 限 流 
(SmoothBursty) 和 平滑 预 热 限 流 (SmoothWarmingUp) 实现 。 


SmoothBursty 
RateLimiter limiter = RateLimiter.create (5); 


System.out .println(limiter.acquire()); 


System.out .println(limiter.acquire()); 
System.out .println(limiter.acquire()); 
System.out .printIn(limiter.acquire()); 
System.out .printIn(limiter.acquire()); 
System.out .println(limiter.acquire()); 
将 得 到 类 似 如 下 的 输出 。 

0.0 

0.198239 

0.196083 

0.200609 

0.199599 


0.19961 


1.RateLimiter.create(5) 表示 棚 容 量 为 5 且 每 秒 新 增 5 个 令 脾 ， 即 每 隔 200 盏 
秒 新 增 一 个 令 牌 。 


2.limiteracquire0 表 示 消 费 一 个 令 牌 。 如 果 当 前 桶 中 有 足够 令 牌 ， 则 成 功 

(返回 值 为 0;” ， 如 果 桶 中 没有 令 牌 ， 则 暂停 一 段 时 间 。 上 比如， 发令 牌 间 
隔 是 200 毫 秒 ， 则 等 待 200 毫 秒 后 再 去 消费 令 牌 〈 如 上 测试 用 例 返 回 
0.198239, RBS 45 T 200M FAA CREAT) ， 这 种 实现 将 突 发 
请 求 速率 平均 为 固定 请 求 速率 。 


再 看 一 个 突 发 示例 。 


RateLimiter limiter = RateLimiter.create(5); 


System.out.println(limiter.acquire(5)); 


System.out.println(limiter.acquire(1)); 


System.out.printIn(limiter.acquire(1)); 

将 得 到 类 似 如 下 的 输出 。 

0.0 

0.98745 

0.183553 

0.199909 

limiteracquire(5) 表 示 桶 的 容量 为 5 且 每 秒 狐 增 5 个 令 牌 。 令 牌 桶 算法 允许 
一 定 程度 的 突 发 ， 所 以 可 以 一 次 性 消费 5 个 令 牌 ， 但 接 下 来 的 


limiteracquire() 将 等 竺 差不多 1 秒 ， 桶 中 才能 有 令 牌 ， 且 接 下 来 的 请 求 也 
整形 为 固定 速率 了 。 


RateLimiter limiter = RateLimiter.create(5); 
System.out.printIn(limiter.acquire(10)); 

System.out.printIn(limiter.acquire(1)); 

System.out.printIn(limiter.acquire(1)); 

将 得 到 类 似 如 下 的 输出 。 

0.0 

1.997428 

0.192273 

0.200616 

同上 面 的 例子 类 似 ， 第 一 秒 突 发 了 10 个 请 求 。 令 牌 桶 算法 也 允许 了 这 种 
突 发 (允许 消费 未 来 的 令 牌 )， 但 接 下 来 的 limiter.acquire(1) 将 等 得 差 不 
多 2 秒 ， 桶 中 才能 有 令 牌 ， 且 接 下 来 的 请 求 也 整形 为 固定 速率 了 。 

接 下 来 再 看 一 个 突 发 的 例子 。 


RateLimiter limiter = RateLimiter.create(2); 
System.out.println(limiter.acquire()); 
Thread.sleep(2000L); 
System.out.println(limiter.acquire()); 
System.out.println(limiter.acquire()); 
System.out.println(limiter.acquire()); 
System.out.println(limiter.acquire()); 
System.out.println(limiter.acquire()); 

将 得 到 类 似 如 下 的 输出 。 

0.0 

0.0 

0.0 

0.0 

0.499876 

0.495799 

1. 创 建 了 一 个 桶 ， 容 量 为 2， 且 每 秒 新 增 2 个 令 脾 。 


2 用 limiter.acquire() 消 费 一 个 令 牌 ， 此 时 令 牌 桶 可 以 满足 (返回 值 为 
0 o 


3. 线 程 暂停 2 秒 ， 接 下 来 的 两 个 limiteracquire0) 都 能 消费 到 令 牌 ， 第 三 个 
limiteracquire0 也 同样 消费 到 了 令 牌 ， 到 第 四 个 时 束 需 要 等 待 500 毫 秒 


PH 


此 处 可 以 看 到 我 们 设置 的 桶 容量 为 2〈 即 允许 的 突 发 量 ) ， 这 是 因为 
SmoothBursty 中 有 一 个 参数 : 最 大 突 发 秒 数 (maxBurstSeconds) ， 默 认 


Mg 


值 为 1sS。 突 发 量 / 桶 容量 = 速率 *maxBurstSeconds， 上 所 以 本 示例 桶 容量 / 突 发 
量 为 2。 例 子 中 前 两 个 是 消费 了 之 前 积攒 的 突 发 量 ， 而 第 三 个 开始 就 是 正 
常 计算 了 。 令 牌 桶 算法 允许 将 一 段 时 间 内 没有 消费 的 令 牌 徊 存 到 令 牌 桶 
中 ， 保 留待 未 来 使 用 ， 并 允许 未 来 请 求 的 这 种 突 发 。 


SmoothBursty 通 过 平均 速率 和 最 后 一 次 新 增 令 牌 的 时 间 计 算出 下 次 新 增 令 
牌 的 时 间 。 另 外 ， 需 要 一 个 桶 暂 存 一 段 时 间 内 没有 使 用 的 令 牌 ( 即 可 以 
突 发 的 令 牌 数 ) 。 另 外 ，RateLimiter 还 提供 了 tryAcquire 方 法 来 进行 无 阻 
塞 或 可 超时 的 令 牌 消费 。 


因为 SmoothBursty 人 允许 一 定 程 度 的 突 发 ， 会 有 人 担心 如 果 人 允许 这 种 突 发 ， 
假设 突然 间 来 了 很 大 的 流量 ， 那 么 系统 很 可 能 打 不 住 这 种 突 发 。 因 此 
需要 一 种 平滑 速率 的 限 流 工具 ， 从 而 在 系统 冷 启动 后 慢 慢 趋 于 平均 固定 
速率 ( 即 刚 开始 速率 小 一 些 ， 然 后 慢 慢 趋 于 我 们 设置 的 固定 速率 ) 。 
Guava 也 提供 了 SmoothWarmingUp 来 实现 这 种 需求 ， 其 可 以 认为 是 漏 桶 算 
法 ， 但 是 在 某 些 特殊 场景 又 不 太一 样 。 


SmoothWarmingUp 


创建 方式 : RateLimiter.create(doublepermitsPerSecond, long warmupPeriod, 
TimeUnit unit) ° 


permitsPerSecond 表 示 每 秒 新 增 的 令 牌 数 ，warmupPeriod 表 示 从 冷 局 动 速 
率 过 渡 到 平均 速率 的 时 间 间 隔 。 


示例 如 下 。 


RateLimiter limiter = RateLimiter.create(5, 1000, TimeUnit.MILLISECONDS); 
for(int 1 = 1; i € 5;it*) { 
System.out.println(limiter.acquire()); 
) 
Thread.sleep(10001); 
for(int i = 1; i < 5;it+) { 
System.out.println(limiter.acquire()); 


) 
将 得 到 类 似 如 下 的 输出 。 
0.0 


0.51767 
0.357814 

0.219992 

0.199984 

0.0 

0.360826 

0.220166 

0.199723 

0.199555 

SIS HC MUEVE USHOR (RUD LEES HOR] cd DLL 
节 warmupPeriod 参 数 实现 一 开始 就 是 平滑 固定 速率 。 

到 此 应 用 级 限 流 的 一 些 方法 就 介绍 完了 。 假 设 将 应 用 部 署 到 多 台 机 器 


上 ， 应 用 级 限 流 方式 只 是 单 应 用 内 的 请 求 限 流 ， 不 能 进行 全 局 限 流 。 因 
此 ， 我 们 需要 用 分 布 式 限 流 和 接 入 层 限 流 来 解决 这 个 问题 。 


43 分布 式 限 流 


分 布 式 限 流 最 关键 的 是 要 将 限 流 服务 做 成 原子 化 ， 而 解决 方案 可 以 使 用 
Redis+Lua 或 者 Nginx+Lua 技 术 进 行 实现 ， 通 过 这 两 种 技术 可 以 实现 高 并 
发 和 高 性 能 。 

首先 ， 我 们 来 使 用 RedistLua 实 现时 间 窗 内 某 个 接口 的 请 求 数 限 流 ， 实 现 
了 该 功能 后 可 以 改造 为 限 流 总 并 发 /请 求 数 和 限制 总 资源 数 。Lua 本 和 喘 就 是 
一 种 编程 语言 ， 也 可 以 使 用 它 实现 复杂 的 令 牌 桶 或 漏 桶 算法 。 


4.3.1 Redis+Lua 实 现 


local key = KEYS[1] -- 限 流 KEY (一 秒 一 个 ) 


local limit = tonumber(ARGV[1]) -- 限 流 大 小 
local current = tonumber (redis.call ("INCRBY", key, "1")) -- 请 求 数 +1 
if current > limit then -- 如 果 超 出 限 流 大 小 

return 0 


elseif current == 1 then -- 只 有 第 一 次 访问 需要 设置 2 秒 的 过 期 时 间 
redis.call("expire", key,"2") 

end 

return 1 


如 上 操作 因 是 在 一 个 Lua 脚 本 中 ， 又 因 Redis 是 单线 程 模型 ， 因 此 线程 安 
全 。 如 上 方式 有 一 个 缺点 就 是 当 达 到 限 流 大 小 后 还 是 会 递增 的 ， 可 以 改 
造成 如 下 方式 实现 。 


local key = KEYS[1] -- 限 流 KEY( 一 秒 一 个 ) 
local limit = tonumber(ARGV[1]) -- 限 流 大 小 
local current = tonumber(redis.call('get', key) or "0") 
if current + 1 > limit then -- 如 果 超 出 限 流 大 小 
return 0 
else -- 请 求 数 +1， 并 设置 2 秒 过 期 
redis.call("INCRBY", key,"1") 
redis.call("expire", key,"2") 
return 1 


end 


如 下 是 Java 中 判断 是 否 需要 限 流 的 代码 。 


public static boolean acquire() throws Exception { 

String luaScript = Files.toString(new File("limit.lua"), 
Charset. defaultCharset()); 

Jedis jedis = new Jedis("192.168.147.52", 6379); 

/ / WC Ab 2 gi EST TH] I Zt 

String key = "ip:" + System.currentTimeMillis()/ 1000; 

Stringlimit = "3"; // 限 流 大 小 

return (Long) jedis.eval (luaScript,Lists.newArrayList (key), 
Lists. newArrayList (limit) )==1; 


} 


因为 Redis 的 限制 (Lua 中 有 写 操作 ， 不 能 使 用 带 随 机 性 质 的 读 操作 ， 如 
TIME) ， 不 能 在 Redis Lua 中 使 用 TIME 获 取 时 间 惟 。 因 此 ， 只 好 从 应 用 
获取 后 传 入 ， 在 某 些 极端 情况 下 (机 器 时 钟 不 准 ) ， 限 流 会 存在 一 些小 


问题 。 


4.3.2 Nginx+Lua 实 现 


local locks = require "resty.lock" 

local function acquire () 

local lock -locks:new ("locks") 

local elapsed, err -lock:lock("limit key") -- 互 斥 锁 
local limit counter -ngx.shared.limit counter -- 计 数 器 
local key = "ip:" ..os.time() 

local limit = 5 -- 限 流 大 小 

local current -limit counter:get (key) 


if current ~= nil and current + 1» limit then -- 如 果 超 出 限 流 大 小 
lock:unlock() 
return 0 
end 
if current -- nil then 
limit counter:set(key, 1 1) -- 第 一 次 需要 设置 过 期 时 间 , 设置 key 的 值 为 1， 
过 期 时 间 为 1 秒 
else 
limit counter:incr(key, 1) -- 第 二 次 开始 加 1 即 可 
end 
lock:unlock() 
return 1 
end 
ngx.print (acquire ()) 


实现 中 我 们 需要 使 用 lua-resty-lock 互 不 锁 模 块 来 解决 原子 性 问题 (在 实际 
工程 中 使 用 时 请 考虑 获取 锁 的 超时 问题 ) ， 并 使 用 ngx.shared.DICT 共 吾 
字典 来 实现 计数 器 。 如 果 需 要 限 流 ， 则 返回 0， 否 则 返回 1。 使 用 时 需要 
先 定义 两 个 共享 字典 (分 别 用 来 存放 锁 和 计数 姻 数 据 ) 。 


lua shared dict locks 10m; 
lua shared dict limit counter 10m; 


) 


AASHU, WARM BIER AK, SDARediszvzrNginxze & Bets 
fk? 不 过 ， 这 个 问题 要 从 多 方面 考虑 : 你 的 流量 是 不 是 真 的 有 这 么 大 ， 
是 不 是 可 以 通过 一 致 性 哈 希 将 分 布 式 限 流 进行 分 片 ? 是 不 是 可 以 当 并 发 
量 太 大 时 降级 为 应 用 级 限 流 ? 对 策 非 常 多 ， 可 以 根据 实际 情况 调节 。 京 
东 目 前 抢购 业务 就 是 使 用 Redis+Lua 来 限 流 的 ， 可 扫 二 维 码 参考 《京东 抢 
购 服务 高 并 发 实践 》。 


对 于 分 布 式 限 流 ， 目 前 过 到 的 场景 是 业务 上 的 限 流 ， 而 不 是 流量 入 口 的 
限 流 。 流 量 入 口 限 流 应 该 在 接 入 层 完成 ， 而 接 入 层 笔者 一 般 使 用 Nginx。 


44 ABR i 


搂 入 层 通 香 指 请 求 流量 的 入 口 ， 该 层 的 主要 目的 有 : 负载 均衡 、 非 法 请 
求 过滤 、 请 求 聚合 、 缓 存 、 降 级 、 限 流 、A/B 测 试 、 服 务 质量 监控 等 ， 可 
以 参考 《使 用 OpenResty 开 发 高 性 能 Web 应 用 》。 


对 于 Nginx 接 入 层 限 流 可 以 使 用 Nginx 自 带 的 两 个 模块 : 连接 数 限 流 模 块 
ngx http limit conn module 和 漏 桶 算法 实现 的 请 求 限 流 模块 


ngx_http_limit_req_module。 还 可 以 使 用 OpenResty 提 供 的 Lua 限 流 模 块 IJua- 
resty-limit-traffic 以 对 更 复杂 的 限 流 场景 。 


limit conn 用 来 对 某 个 key 对 应 的 总 的 网 络 连接 数 进 行 限 流 ， 可 以 按照 如 

IP、 域 名 维度 进行 限 流 。limit_req 用 来 对 某 个 key 对 应 的 请 求 的 平均 速率 

E 有 两 种 用 法 : 平滑 模式 (delay) 和 人 允许 突 发 模式 
nodelay) ° 


4.4.1  ngx http limit conn module 


limit_conmn 是 对 某 个 key 对 应 的 总 的 网 络 连 接 数 进行 限 流 。 可 以 按照 IP 来 限 
制 卫 维度 的 总 连接 数 ， 或 者 按照 服务 域名 来 限制 某 个 域名 的 总 连接 数 。 
但 是 ， 记 住 不 是 每 个 请 求 连 接 都 会 被 计数 器 统 计 ， 只 有 那些 被 Nginx 人 处 理 
的 且 已 经 读 了 到了 整个 请 求 头 的 请 求 连接 才 会 被 计数 万 统计 。 


1. 配 置 示例 


http { 
limit conn zone $binary remote addr zone=addr:10m; 


limit conn log level error; 
limit conn status 503; 


server { 
location /limit { 
limit conn addr 1; 


} 


.limit conn: ”要 配置 存放 key 和 计数 器 的 共享 内 存 区 域 和 指定 key 的 最 大 
。 此 处 指定 的 最 大 连接 数 是 1， 表 示 Nginx 最 多 同时 并 发 处 理 1 个 连 
x o 


limit conn zone: ”用 来 配置 限 流 key 及 存放 key 对 应 信息 的 共享 内 存 区 域 
大 小 。 此 处 的 key 是 “$binary_remote_addr”， 表 示 IP 地 1 HE, 也 可 以 使 用 
$server_name 作 为 key 来 限制 域名 级 别 的 最 大 连 车 接 数 。 


limit conn status: ”配置 被 限 流 后 返回 的 状态 码 ， 默 认 返 回 503。 
` limit conn log level: 配置 记录 被 限 流 后 的 日 志 级 别 ， 默 认 error 级 别 。 
2.limit comn 的 主要 执行 过 程 


/ 


请 求 进入 后 首先 判断 当前 limit_conn_zone 中 相应 key 的 连接 数 是 否 
配置 的 最 大 连接 数 。 


` 如 果 超 过 了 配置 的 最 大 大 小 ， 则 被 限 流 ， 返 回 ]limit_conn_status 定 义 的 错 
| UMS 否则 相应 key 的 连接 数 加 1， 并 注册 请 求 处 理 完成 的 回调 函 


超出 了 


进行 请 求 处 理 。 
.在 结束 请 求 阶段 会 调用 注册 的 回调 画 数 对 相应 key 的 连接 数 减 1 。 
limt_conn 可 以 限 流 某 个 key 的 总 并 发 /请 求 数 ，key 可 以 根据 需要 变化 。 
3. 按 照 IP 限 制 并 发 连接 数 配 置 示例 

首先 ， 定 义 IP 维 度 的 限 流 区 域 。 


limit conn, zone $binary remote addr zone-perip:10m; 
接着 在 要 限 流 的 location 中 添加 限 流 逻 辑 。 


location /limit { 
limit conn perip 2; 
echo "123"; 


} 

即 人 允许 每 个 了 了 最 大 并 发 连接 数 为 2。 

使 用 AB 测 试 工具 进行 测试 ， 并 发 数 为 5 个 ， 总 的 请 求 数 为 5 个 。 
ab -n 5 -c 5 http://localhost/limit 

将 得 到 如 下 access.log 输 出 。 

[08/Jun/2016:20:10:51+0800] [1465373451.802] 200 
[08/Jun/2016:20:10:51+0800] [1465373451.803] 200 


[08/Jun/2016:20:10:51 +0800][1465373451.803] 503 


[08/Jun/2016:20:10:51 +0800][1465373451.803] 503 
[08/Jun/2016:20:10:51 +0800][1465373451.803] 503 


此 处 我 们 把 access log 格 式 设置 为 log_format main — '[$time local] [$msec] 
$status; 参数 分 别 表示 时 间 、 时 间 / 训 秒 值 和 响应 状态 码 。 


如 果 被 限 流 ， 则 在 errorlog 中 会 看 到 类 似 如 下 的 内 容 。 


2016/06/08 20:10:51 [error] 5662#0: *5limiting connections by zo"npee rip", 
client: 127.0.0.1, server: _,request: "GET i/mlit HTTP/1.0", host: "localhost" 


4. 按 照 域 名 限制 并 发 连接 数 配 置 示例 
首先 ， 定 义 域名 维度 的 限 流 区 域 。 


limit conn zone $server_name zone=perserver:10m; 


接着 在 要 限 流 的 location 中 添加 限 流 逻辑 。 


location /limit { 


limit conn perserver 2; 
echo "123"; 
} 


即 允 许 每 个 域名 最 大 并 发 请 求 连 接 数 为 2。 这 样 配置 可 以 实现 服务 器 最 大 
连接 数 限 制 。 


4.4.2 ngx http limit req module 


limit_req 是 漏 桶 算法 实现 ， 用 于 对 指定 key 对 应 的 请 求 进行 限 流 ， 比 如 ， 
按照 IP 维 度 限制 请 求 速率 。 配 置 示例 如 下 。 


http { 
limit req zone $binary remote addr zone=one:10m rate-1r/s; 


limit conn log level error; 
limit conn status 503; 


server { 


location /limit { 
limit req zone-one burst-5 nodelay; 


) 


limit req: 配置 限 流 区 域 、 桶 容量 ( 突 发 容量 ， 默 认为 0) 、 是 否 延迟 
模式 (默认 延迟 ) 。 


-limit_req_zone: ”配置 限 流 key、 存 放 key 对 应 信息 的 共享 内 存 区 域 大 
小 、 固 定 请 求 速率 。 此 处 指定 的 key 是 “$binary_remote_addr”"， 表 示 IP 地 
址 。 固 定 请 求 速率 使 用 rate 参 数 配置 ， 文 持 10s 和 60vm， 即 每 秒 10 个 请 
求 和 每 分 钟 60 个 请 求 。 不 过 ， 最 终 都 会 转换 为 每 秒 的 固定 请 求 速率 

410rs 为 每 100 毫 秒 处 理 一 个 请 求 ，60vm 为 每 1000 毫 秒 处 理 一 个 请 


` 


limit conn status: 配置 被 限 流 后 返回 的 状态 码 ， 默 认 返 回 503。 
: limit conn log level: 配置 记录 被 限 流 后 的 日 志 级 别 ， 默 认 级 别 为 


error ° 
limit_req 的 主要 执行 过 程 如 下 。 


(1) 请求 进入 后 首先 判断 最 后 一 次 请 求 时 间 相 对 于 当前 时 间 (第 一 次 是 
) 是 否 需要 限 流 ， 如 果 需 要 限 流 ， 则 执行 步骤 2， 和 否则 执行 步 又 3 。 


(2) 如 果 没 有 配置 桶 容量 (burst) ， 则 桶 容量 为 0， 按 照 固 定 速率 处 理 
请 求 。 如 果 请 求 被 限 流 ， 则 直接 返回 相应 的 错误 码 (默认 为 503) 。 


如 果 配 置 了 桶 容量 (burst>0) 及 延迟 模式 (没有 配置 nodelay) 。 如 果 桶 
满 了 ， 则 新 进入 的 请 求 被 限 流 。 如 果 没 有 满 ， 则 请 求 会 以 固定 平均 速率 
E (按照 固定 速率 并 根据 需要 延迟 处 理 请 求 ， 延 迟 使 用 休眠 实 
Ju o 


如 果 配 置 了 桶 容量 (burst>0) 及 非 延 迟 模式 (配置 了 nodelay) ， 则 不 会 
按照 固定 速率 处 理 请 求 ， 而 是 允许 突 发 处 理 请 求 。 如 果 桶 满 了 ， 则 请 求 
被 限 流 ， 直 接 返 回 相 应 的 错误 码 。 


0 


(3) 如 果 没 有 被 限 流 ， 则 正常 处 理 请 求 。 


(4) Nginx 会 在 相应 时 机 选择 一 些 (3 个 节点 ) 限 流 key 进 行 过 期 处 理 ， 
进行 内 存 回 收 。 


1. 场 景 2.1 测 试 

首先 ， 定 义 IP 维 度 的 限 流 区 域 。 

limit req zone $binary_remote_addr zone=test:10m rate=500r/s; 
限制 为 每 秒 500 个 请 求 ， 固 定 平 均 速率 为 2 毫秒 一 个 请 求 。 
接着 在 要 限 流 的 location 中 添加 限 流 逻辑 。 


location /limit { 
limit req zone-test; 
echo "123"; 

} 


即 桶 容量 为 0 (burst 默 认为 0) 且 延 迟 模式 。 

使 用 AB 测 试 工具 进行 测试 ， 并 发 数 为 2 个 ， 总 的 请 求 数 为 10 个 。 
ab -n 10 -c 2 http://localhost/limit 

将 得 到 如 下 access.log 输 出 。 

[08/Jun/2016:20:25:56+0800] [1465381556.410] 200 
[08/Jun/2016:20:25:56 +0800][1465381556.410] 503 
[08/Jun/2016:20:25:56 +0800][1465381556.411] 503 
[08/Jun/2016:20:25:56+0800] [1465381556.411] 200 
[08/Jun/2016:20:25:56 +0800][1465381556.412] 503 


[08/Jun/2016:20:25:56 +0800][1465381556.412] 503 


虽然 ， 每 秒 允 许 500 个 请 求 ， 但 是 ， 因 为 桶 容量 为 0， 所 以 流入 的 请 求 要 
么 被 处 理 要 么 被 限 流 ， 无 法 延迟 处 理 。 另 外 ， 平 均 速 率 在 2 毫秒 左右 ， 比 
如 1465381556.410 和 1465381556.411 被 处 理 了 。 有 朋友 会 说 固定 平均 速率 
不 是 1 毫秒 吗 ? 其 实 这 是 因为 实现 算法 没 那 么 精准 造成 的 。 


如 果 被 限 流 在 errorlog 中 ， 则 会 看 到 如 下 内 容 。 


2016/06/08 20:25:56 [error] 6130#0: *1962limiting requests, excess: 1.000 by 
zone "test", client: 127.0.0.1,server: _, request "GET /limit HTTP/1.0", 
host:"localhost" 


如 采 被 延迟 ， 那么 在 error.log (日 志 级 别 要 INFO 级 别 ) 中 会 看 到 如 下 内 
X o 


2016/06/10 09:05:23 [warn] 9766#0: *97021delaying request, excess: 0.368, 
by zone "test", client: 127.0.0.1,server: _, request: "GET /limit HTTP/1.0", 
host:"localhost" 


2. 场 景 2.2 测 试 
惠 和 匈 ， 定 义 卫 维度 的 限 流 区 域 。 
limit req zone $binary remote addr zone=test:10m rate=2r/s; 


为 了 方便 测试 设置 速率 为 每 秒 2 个 请 求 ， 即 固定 平均 速率 是 500 毫 秒 一 个 
请 求 。 


接着 在 要 限 流 的 location 中 添加 限 流 逻辑 。 


location /limit { 
limit req zone-test burst=3; 
echo "123"; 

} 
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求 被 限 流 ， 否 则 可 以 进入 桶 中 排队 并 等 待 (实现 延迟 模式 ) 。 为 了 看 出 
限 流 效果 我 们 写 了 一 个 req.sh 脚 本 。 


ab -c 6 -n 6http://localhost/limit 


sleep 0.3 

ab -c 6 -n 6 http://localhost/limit 

首先 ， 进 行 6 个 并 发 请 求 6 次 URL ， 然 后 休眠 300 坚 秒 ， 再 进行 6 个 并 发 请 
求 6 次 URL。 中 间 休 眠 目的 是 为 了 能 跨越 2 秒 看 到 效果 ， 如 采 看 不 到 如 下 
的 效果 ， 则 可 以 调 市 休眠 时 间 。 

将 得 到 如 下 access.log 输 出 。 


[09/Jun/2016:08:46:43+0800] [1465433203.959] 200 


[09/Jun/2016:08:46:43 +0800][1465433203.959] 503 
[09/Jun/2016:08:46:43 +0800][1465433203.960] 503 
[09/Jun/2016:08:46:44+0800] [1465433204.450] 200 
[09/Jun/2016:08:46:44+0800] [1465433204.950] 200 
[09/Jun/2016:08:46:45 +0800][1465433205.453] 200 
[09/Jun/2016:08:46:45 +0800][1465433205.766] 503 
[09/Jun/2016:08:46:45 +0800][1465433205.766] 503 
[09/Jun/2016:08:46:45 +0800][1465433205.767] 503 
[09/Jun/2016:08:46:45+0800] [1465433205.950] 200 
[09/Jun/2016:08:46:46+0800] [1465433206.451] 200 


[09/Jun/2016:08:46:46+0800] [1465433206.952] 200 


一 一 1.5 秒 (相对 十 2.459 秒 ) ; 0 个 


— 1.0 秘 {相对 于 2.959 秒 ) : 0 个 
3.959 本 次 ，3 个 {delay) + 1 个 
和 4.450 
P 4.950 
r 1.5 秒 《相对 于 4.266 种 ) : 0 个 
5.453 A 10 秒 (相对 于 4.950 秒 》: 1 个 
/ EK: 3 个 (delay) 
5.766 i 
第 5.950 | 
H 
6.451 | 
6.952 | 


桶 容量 为 3， 即 桶 中 在 时 间 窗 口内 最 多 流入 3 个 请 求 ， 且 按照 2rs 的 固定 速 
率 处 理 请 求 〈 即 每 隔 500 萤 秒 处 理 一 个 请 求 ) 。 桶 计算 时 间 窗 口 (1.595) 
= 速率 〈2rs) / 桶 容量 (3)， 也 就 是 说 在 这 个 时 间 窗 口内 桶 最 多 暂 存 3 个 请 
求 。 因 此 ， 我 们 要 以 当前 时 间 往 前 推 1.5 秒 和 1 秒 来 计算 时 间 窗 口内 的 总 请 
求 数 。 男 外 ， 因 为 默认 是 延迟 模式 ， 所 以 时 间 窗 内 的 请 求 要 被 暂 存 到 桶 
中 ， 并 以 固定 平均 速率 处 理 请 求 。 


第 一 轮 : 有 4 个 请 求 处 理 成 功 了 ， 按 照 漏 桶 算法 桶 容量 应 该 最 多 3 个 才 
对 。 这 是 因为 计算 算法 的 问题 ， 第 一 次 计算 因 没 有 参考 值 ， 所 以 第 一 次 
计算 后 ， 后 续 的 计算 才能 有 参考 值 ， 因 此 ， 第 一 次 成 功 可 以 忽略 。 这 个 
问题 影响 很 小 ， 可 以 忽略 。 而 且 ， 可 按照 固定 500 蝇 秒 的 速率 处 理 请 求 。 


第 二 轮 : 因为 第 一 轮 请 求 是 突 发 的 ， 差 不 多 都 在 1465433203.959 时 间 点 ， 
只 是 因为 漏 桶 将 速率 进行 了 平滑 ， 变 成 了 固定 平均 速率 〈 每 500 训 秒 一 个 
请 求 ) 。 第 二 轮 计 算 时 间 应 基于 1465433203.959。 而 第 二 轮 突 发 请 求 差 不 
多 都 在 1465433205.766 时 间 点 ， 因 此 ， 计 算 桶 容量 的 时 间 窗 口 应 基于 
1465433203.959 和 1465433205.766 来 计算 ， 计 算 结 果 为 1465433205.766 这 
个 时 间 点 漏 桶 为 空 了 ， 可 以 流入 桶 中 3 个 请 求 ， 其 他 请 求 被 拒绝 。 又 因为 
第 一 轮 最 后 一 次 处 理 时 间 是 1465433205.453， 所 以 第 二 轮 第 一 个 请 求 被 延 
迟到 了 1465433205.950。 这 里 也 要 注意 固定 平均 速率 只 是 在 配置 的 速率 左 
右 ， 存 在 计算 精度 问题 ,会 有 一 些 偏差 。 


如 果 桶 容量 改 为 1 (burst=1) ， 则 执行 req.sh 脚 本 可 以 看 到 如 下 输出 。 


09/Jun/2016:09:04:30+0800] [1465434270.362] 200 
[09/Jun/2016:09:04:30 +0800][1465434270.371] 503 
[09/Jun/2016:09:04:30 +0800] [1465434270.372]503 
[09/Jun/2016:09:04:30 +0800][1465434270.372] 503 
[09/Jun/2016:09:04:30 +0800][1465434270.372] 503 
[09/Jun/2016:09:04:30+0800] [1465434270.864] 200 
[09/Jun/2016:09:04:31 +0800][1465434271.178] 503 
[09/Jun/2016:09:04:31 +0800][1465434271.178] 503 
[09/Jun/2016:09:04:31 +0800][1465434271.178] 503 
[09/Jun/2016:09:04:31 +0800][1465434271.178] 503 
[09/Jun/2016:09:04:31 +0800][1465434271.179] 503 
[09/Jun/2016:09:04:31+0800] [1465434271.366] 200 
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3. 场 景 2.3 测 试 

首先 ， 定 义 IP 维 度 的 限 流 区 域 。 

limit req zone $binary_remote_addr zone=test:10m rate=2r/s; 

为 了 方便 测试 配置 为 每 秒 2 个 请 求 ， 固 定 平均 速率 是 500 毫 秒 一 个 请 求 。 
接着 在 要 限 流 的 location 中 添加 限 流 逻辑 。 


location /limit { 
limit req zone=test burst-3 nodelay; 
echo "123"; 


桶 容量 为 3， 如 末 桶 满 了 ， 则 直接 拒绝 新 请 求 ， 且 每 2 秒 最 多 两 个 请 求 ， 
桶 按照 固定 500 营 秒 的 速率 以 nodelay 模 式 处 理 请 求 。 


为 了 看 到 限 流 效果 ， 我 们 写 了 一 个 req.sh 脚 本 。 
ab -c 6 -n 6http://localhost/limit 

sleep 1 

ab -c 6 -n 6http://localhost/limit 

sleep 0.3 

ab -c 6 -n 6http://localhost/limit 

sleep 0.3 

ab -c 6 -n 6http://localhost/limit 

sleep 0.3 

ab -c 6 -n 6http://localhost/limit 

sleep 2 

ab -c 6 -n 6 http://localhost/limit 

将 得 到 类 似 如 下 的 access.log 输 出 。 
[09/Jun/2016:14:30:11+0800] [1465453811.754] 200 
[09/Jun/2016:14:30:11+0800] [1465453811.755] 200 
[09/Jun/2016:14:30:11+0800] [1465453811.755] 200 
[09/Jun/2016:14:30:11+0800] [1465453811.759] 200 
[09/Jun/2016:14:30:11 +0800][1465453811.759] 503 


[09/Jun/2016:14:30:11 +0800][1465453811.759] 503 


[09/Jun/2016:14:30:12+0800] [1465453812.776] 200 
[09/Jun/2016:14:30:12+0800] [1465453812.776] 200 
[09/Jun/2016:14:30:12 +0800][1465453812.776] 503 
[09/Jun/2016:14:30:12 +0800][1465453812.777] 503 
[09/Jun/2016:14:30:12 +0800][1465453812.777] 503 
[09/Jun/2016:14:30:12 +0800][1465453812.777] 503 
[09/Jun/2016:14:30:13 +0800] [1465453813.095]503 
[09/Jun/2016:14:30:13 +0800][1465453813.097] 503 
[09/Jun/2016:14:30:13 +0800][1465453813.097] 503 
[09/Jun/2016:14:30:13 +0800][1465453813.097] 503 
[09/Jun/2016:14:30:13 +0800][1465453813.097] 503 
[09/Jun/2016:14:30:13 +0800][1465453813.098] 503 
[09/Jun/2016:14:30:13+0800] [1465453813.425] 200 
[09/Jun/2016:14:30:13 +0800][1465453813.425] 503 
[09/Jun/2016:14:30:13 +0800][1465453813.425] 503 
[09/Jun/2016:14:30:13 +0800][1465453813.426] 503 
[09/Jun/2016:14:30:13 +0800][1465453813.426] 503 
[09/Jun/2016:14:30:13 +0800][1465453813.426] 503 
[09/Jun/2016:14:30:13+0800] [1465453813.754] 200 
[09/Jun/2016:14:30:13 +0800][1465453813.755] 503 


[09/Jun/2016:14:30:13 +0800][1465453813.755] 503 


[09/Jun/2016:14:30:13 +0800][1465453813.756] 503 
[09/Jun/2016:14:30:13 +0800][1465453813.756] 503 
[09/Jun/2016:14:30:13 +0800][1465453813.756] 503 
[09/Jun/2016:14:30:15+0800] [1465453815.278] 200 
[09/Jun/2016:14:30:15+0800] [1465453815.278] 200 
[09/Jun/2016:14:30:15+0800] [1465453815.278] 200 
[09/Jun/2016:14:30:15 +0800][1465453815.278] 503 
[09/Jun/2016:14:30:15 +0800][1465453815.279] 503 
[09/Jun/2016:14:30:15 +0800][1465453815.279] 503 
[09/Jun/2016:14:30:17+0800] [1465453817.300] 200 
[09/Jun/2016:14:30:17+0800] [1465453817.300] 200 
[09/Jun/2016:14:30:17+0800] [1465453817.300] 200 
[09/Jun/2016:14:30:17+0800] [1465453817.301] 200 
[09/Jun/2016:14:30:17 +0800][1465453817.301] 503 


[09/Jun/2016:14:30:17 +0800][1465453817.301] 503 
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桶 容量 为 3 〈 即 桶 中 在 时 间 窗 口内 最 多 流入 3 个 请 求 ) ， 且 按照 2vs 的 固定 
速率 处 理 请 求 〈 即 每 隔 500 毫 秒 处 理 一 个 请 求 ) 。 桶 计算 时 间 窗 口 (L5 
秒 ) = 速率 (2r/s) / 桶 容量 (3) ， 也 就 是 说 在 这 个 时 间 窗 口内 桶 最 多 和 暂 存 
3 个 请 求 。 因此， 我 们 要 以 当前 时 间 往 前 推 1.5 秒 和 1 秒 来 计算 时 间 窗 口内 
的 总 请 求 数 。 另 外 ， 因 为 配置 了 nodelay， 是 非 延 迟 模式 ， 所 以 允许 时 间 
窗 内 的 突 发 请 求 。 男 外 ， 从 本 示例 中 会 看 出 两 个 问题 。 


第 一 轮 和 第 七 轮 : 有 4 个 请 求 处 理 成 功 了 。 这 是 因为 计算 算法 的 问题 ， 本 
示例 是 如 有 果 2 秒 内 没有 请 求 ， 然 后 突然 来 了 很 多 请 求 ， 那 么 第 一 次 计算 的 
结 末 将 是 不 正确 的 ， 这 个 问题 影响 很 小 ， 可 以 忽略 。 

第 五 轮 : 1.0 秒 计算 出 来 的 古 3 个 请 求 。 此 处 也 是 因 计 算 精 度 的 问题 ， 也 束 
是 说 limit_ req 实 现 的 算法 不 是 非常 精准 ， 假 设 此 处 看 成 相对 于 2.75 的 话 ， 
1.0 秒 内 只 有 1 次 请 求 ， 所 以 还 是 允许 1 次 请 求 的 。 


如 采 限 流出 错 了 ， 则 可 以 配置 错误 页 面 。 


proxy_intercept_errors on; 
recursive_error_pages on; 


error page 503 //www.jd.com/error.aspx; 


limit_conn_zone/limit_req_zone 定 义 的 内 存 不 足 ， 则 后 续 的 请 求 将 一 直 被 
限 流 ， 所 以 需要 根据 需求 设置 好 相应 的 内 存 大 小 。 


此 处 的 限 流 都 是 单 Nginx 的 ， 假 设 我 们 接 入 层 有 多 个 Nginx， 此 处 就 存在 
和 应 用 级 限 流 相同 的 问题 。 那 如 何 处 理 呢 ? 一 种 解决 办 法 是 建立 一 个 负 
载 均衡 层 ， 按 照 限 流 key 进 行 一 致 性 哈 希 算法 ， 将 请 求 哈 硕 到 接 入 层 
Nginx 上， 从 而 相同 key 的 请 求 将 打 到 同一 台 接 入 层 Nginx 上 。 男 一 种 解决 
方案 就 是 使 用 Nginx+Lua (OpenResty) 调用 分 布 式 限 流 逻 辑 实现 。 


4.4.3 lua-resty-limit-traffic 


之 前 介绍 的 两 个 模块 在 使 用 上 比较 简单 ， 指 定 key、 指 定 限 流 速率 等 就 可 
以 了 。 如 果 想 根据 实际 情况 变化 key、 速 率 、 桶 大 小 等 这 种 动态 特性 ， 那 
么 使 用 标准 模块 束 很 难 去 实现 了 。 因 此 ， 需 要 一 种 可 编程 方式 来 解决 我 
们 的 问题 。 而 OpenResty 提 供 了 Lua 限 流 模 块 lua-resty-limit-traffic， 通 过 它 
可 以 按照 更 复杂 的 业务 逻辑 进行 动态 限 流 处 理 。 其 提供 了 limit.conn 和 
limit.req 实 现 ， 算 法 与 nginx limit conn 和 limit_req 是 一 样 的 。 


此 处 我 们 来 实现 ngx_http_limit_req_module 中 的 【场景 2.2 测 试 】， 不 要 起 
记 下 载 lua-resty-limit-traffic 模 块 并 添加 a 到 OpenResty 的 lualib 中 。 


配置 用 来 存放 限 流 用 的 共享 字典 。 


lua shared dict limit req store 100m; 


以 下 是 实现 【场景 2.2 测 试 】 的 限 流 代码 limit_req.lua 。 


local limit req = require "resty.limit.req" 
local rate = 2 -- 固 定 平均 速率 2r/s 
local burst = 3 -- 桶 容量 


local error status = 503 
local nodelay = false -- 是 否 需要 不 延迟 处 理 
local lim, err = limit req.new("limit req store", rate, burst) 


if not lim then -- 没 定义 共享 字典 
ngx.exit(error status) 
end 
local key = ngx.var.binary remote addr --IP 维度 的 限 流 
-- 流 入 请 求 ， 如 果 请 求 需要 被 延迟 ， 则 delay > 0 
local delay, err = lim:incoming(key, true) 
if not delay and err == "rejected" then -- 超 出 桶 大 小 了 
ngx.exit(error status) 
end 
if delay > 0 then -- 根 据 需要 决定 是 延迟 或 者 不 延迟 处 理 
if nodelay then 
-- 直 接 突 发 处 理 了 
else 
ngx.sleep(delay) -- 延 迟 处 理 
end 
end 


即 限 流 逻辑 在 Nginx access 阶 段 被 访问 ， 如 果 不 被 限 流 ， 则 继续 后 续 流 
程 。 如 琳 需 要 被 限 流 ， 则 要 么 sleep 一 段 时 间 继 续 后 续 流程 ， 要 么 返回 相 
应 的 状态 码 拒 绝 请 求 。 


在 分 布 式 限 流 中 ， 我 们 使 用 了 简单 的 Nginx+Lua 进 行 分 布 式 限 流 ， 有 了 这 
个 模块 也 可 以 使 用 这 个 模块 来 实现 分 布 式 限 流 。 


另外 ， 在 使 用 Nginx+Lua 时 也 可 以 获取 ngx.var.connections_active 进 行 过 载 
保护 ， 即 如 果 当 前 活跃 连接 数 超过 国 值 ， 则 进行 限 流 保护 。 


if tonumber(ngx.var.connections active) >= tonumber(limit) then 
/ / WR if 


end 


Nginx 也 提供 了 limit_rate 用 来 对 流量 限 速 ， 如 limit_rate 50k， 表 示 限 制 下 
载 速度 为 50k ° 


到 此 笔者 在 工作 中 涉及 的 限 流 用 法 就 介绍 完了 ， 这 些 算法 中 有 些 允 许 突 
发 ， 有 些 会 整形 为 平滑， 有 些 计算 算法 简单 粗暴 。 其 中 ， 令 牌 桶 算法 和 
漏 桶 算法 实现 上 是 类 似 的 ， 只 是 表 壕 的 方向 不 太一 样 ， 对 于 业务 来 说 不 
必 刻 意 去 区 分 它们 。 因 此 ， 和 需要 根据 实际 场景 来 决定 如 何 限 流 ， 最 好 的 
算法 不 一 定 是 最 适用 的 。 
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有 时 候 我 们 想 在 特定 时 间 窗 口内 对 重复 的 相同 事件 最 多 只 处 理 一 次 ， 或 
者 想 限 制 多 个 连续 相同 事件 最 小 执行 时 间 间 隔 ， 那 么 可 使 用 节 流 

(Throttle) 实现 ， 其 防止 多 个 相同 事件 连续 重复 执行 。 方 流 主要 有 如 下 
几 种 用 法 : throttleFirst ^ throttleLast ^ throttleWithTimeout ° 


4.5.1 throttleFirst/throttleLast 


throttleFirst/ throttleLast 是 指 在 一 个 时 间 窗 口内 ， 如 果 有 重复 的 多 个 相同 事 
件 要 处 理 ， 则 只 处 理 第 一 个 或 最 后 一 个 。 其 相当 于 一 个 事件 频率 控制 
器 ， 把 一 段 时 间 内 重复 的 多 个 相同 事件 变 为 一 个 ， 减 少 事件 处 理 频 率 ， 
从 而 减少 无 用 处 理 ， 提 升 性 能 。 


throttleFirst 


(0 © YY © 
Oms 100ms 200ms 300ms 400ms 
© © © | 
© G G 90 © biduo ad 
Oms 100ms 200ms 300ms 400ms 
(2) (5) (6) 


如 上 图 所 示 ，throttleFirst 在 一 个 时 间 窗 口内 只 会 处 理 该 时 间 窗 口内 的 第 一 
qase 


而 throttleLast 会 处 理 该 时 间 窗 口内 的 最 后 一 个 事件 。 
一 个 场景 是 网 页 中 的 resize、scrol 和 mousemove 事件 ， 当 我 们 改变 浏览 器 


大 小 时 会 触发 resize 事 件 ， 而 滚动 页 面 元 素 时 会 触发 scroll 事 件 。 当 我 们 快 
速 连续 执行 这 些 操 作 时 会 连续 触发 这 些 事 件 ， 那 么 可 能 因此 造成 UI 反应 


慢 、 浏 览 器 卡 顿 ， 因 此 币 流 歼 派 上 用 场 了 。 对 于 前 端 开 发 ， 可 以 使 用 
jquery-throttle-debounce-plugin 实 现 ， 而 Android 开 发 可 以 使 用 RxAndroid 实 
现 。 


4.5.2 throttleWithTimeout 


throttleWithTimeout 也 叫 作 debounce (ZEE) , ， 限 制 两 个 连续 事件 的 先后 
执行 时 间 不 得 小 于 某 个 时 间 窗 口 。 


= - "EC = throttleWithTimeout 
(1) (2) (3) (4)(5 — = (6) - | 


| Oms 100ms | 200ms | 300ms 400ms 


(100ms) e | (100ms) (6) | 


如 上 图 所 示 ，throttleWithTimeout 限 制 两 个 连续 事件 的 最 小 间隔 时 间 窗 
口 。throttleFirst throttleLast 是 基于 决定 时 间 做 的 处 理 ， 是 以 固定 时 间 窗 口 
为 基准 ， 对 同一 个 国定 时 间 窗 口内 的 多 个 连续 事件 最 多 只 处 理 一 个 。 而 
throttleWithTimeout 是 基于 两 个 连续 事件 的 相对 时 间 ， 当 两 个 连续 事件 的 
间隔 时 间 小 于 最 小 间隔 时 间 窗 口 ， 就 会 丢弃 上 一 个 事件 ， 而 如 果 最 后 一 
个 事件 等 每 了 最 小 间隔 时 间 帘 口 后 还 没有 新 的 事件 到 来 ， 那 么 会 处 理 最 
后 一 个 事件 。 

如 搜索 关键 词 自动 补 人 全， 如果 用 户 每 录入 一 个 字 就 发 送 一 次 请 求 ， 而 先 
输入 的 字 的 目 动 补 全 会 被 很 快 到 来 的 下 一 个 字符 履 盖 ， 那 么 会 导致 先期 
的 自动 补 全 是 元 用 的 。throttleWithTimeout 就 是 来 解决 这 个 问题 的 ， 通 过 
它 来 减少 频繁 的 网 络 请 求 ， 避 人 免 每 输入 一 个 字 就 导致 一 次 请 求 。 


使 用 RxJava 1.2.0 实 现 的 测试 代码 。 


Observable 
.create(new Observable.OnSubscribe<Integer>() { 
@Override 
public void call (Subscriber<? super Integer» subscriber) 
//next 实现 : Thread.sleep (millis); subscriber.onNext ( 


next(subscriber, 1 a / / 0ms 
next(subscriber, 2, 50); //50ms 
next(subscriber, 3, 50); //100ms 
next(subscriber, 4, 30); //130ms 
next(subscriber, 5, 40); //170ms 
next(subscriber, 6, 130 

( 


2$ //300ms 
); 


, 


subscriber. aeo 


}) 

. subscribeOn (Schedulers.newThread() ) 
.throttleWithTimeout (100, TimeUnit.MILLISECONDS) 
. subscribe (new Subscriber<Integer>() { 


OTETI 


@Override 
public void onNext (Integer i) { 
System.out.printin("=="_+ i); 
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i); 


5 ”降级 特技 


在 开发 高 并 发 系统 时 ， 有 很 多 手段 来 保护 系统 ， 如 缓存 、 降 级 和 限 流 
等 。 本 章 来 聊 聊 降级 策略 。 当 访问 量 剧 增 、 服 务 出 现 问 题 《如 啊 应 时 间 
长 或 不 啊 应 ) 或 非 核 心服 务 影响 到 核心 流程 的 性 能 时 ， 仍 然 需要 保证 服 
务 还 是 可 用 的 ， 即 使 是 有 损 服 务 。 系 统 可 以 根据 一 些 关 键 数据 进行 自动 
降级 ， 也 可 以 配置 开关 实现 人 工 降 级 。 本 文 将 介绍 一 些 笔者 在 实际 工作 
中 遇 到 的 或 见 到 过 的 一 些 降 级 方案 ， 供 大 家 参考 。 


降级 的 最 终 目 的 是 保证 核心 服务 可 用 ， 即 使 是 有 损 的 。 而 且 有 些 服务 是 


无 法 降级 的 〈 如 加 入 购物 车 、 结 算 ) 。 降 级 也 需要 根据 系统 的 吞吐 量 、 
啊 应 时 间 、 可 用 率 等 条 件 进 行 手 工 降级 或 自动 降级 。 


5.1 降级 预案 


在 进行 降级 之 前 要 对 系统 进行 梳理 ， 看 看 系统 是 不 是 可 以 丢 鞭 保 帅 ， 从 
有 
UE ° 


一般: 比如 ， 有 些 服务 偶尔 因为 网 络 拌 动 或 者 服务 正在 上 线 而 超时 ， 可 
以 自动 降级 。 


BE. 有 些 服务 在 一 段 时 间 内 成 功率 有 波动 (如 在 95~100% 之 间 ) ， 可 
以 自动 降级 或 人 工 降 级 ， 并 发 送 告警 。 

- 错误 : ， 比如， 可 用 率 低 于 90%， 或 者 数据 库 连 接 池 用 完了 ， 或 者 访问 量 
工 降 级 。 
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降级 按照 是 否 目 动 化 可 分 为 : 目 动 开关 降级 和 人 工 开 关 降 级 。 
降级 按照 功能 可 分 为 ， 读 服务 降级 和 写 服务 降级 。 
降级 按照 处 于 的 系统 层次 可 分 为 ， 多 级 降级 。 


降级 的 功能 点 主要 从 服务 器 端 链 路 考虑 ， 即 根据 用 户 访问 的 服务 调用 链 
路 来 梳理 哪里 需要 降级 。 


页 面 降 级 : 在 大 促 或 者 某 些 特殊 情况 下 ， 某 些 页 面 占 用 了 一 些 稀缺 服务 
资源 ， 在 紧急 情况 下 可 以 对 其 整个 降级 ， 以 达到 丢 座 保 是 的 目的 。 


- 页 面 片段 降级 : 比如 ， 商 品 详情 页 中 的 商家 部 分 因为 数据 错误 ， 此 时 ， 
需要 对 其 进行 降级 。 


页 面 异步 请 求 降级 : 比如 ， 商 品 详情 页 上 有 推荐 信息 /配送 至 等 异步 加 
"M 如 果 这 些 信息 响应 慢 或 者 后 端 服务 有 问题 ， 则 可 以 进行 降 
` 服务 功能 降级 : 比如 ， 泻 染 商 品 详情 页 时 ， 需 要 调用 一 些 不 太 重要 的 服 
` 热 销 榜 等 ) ， 而 这 些 服务 在 异常 情况 下 直接 不 获取 ， 即 
BABY A] ° 


TEER: 比如 ， 多 级 缓存 模式 ， 如 果 后 端 服务 有 问题 ， 则 可 以 降级 为 只 
读 缓 存 ， 这 种 方式 适用 于 对 读 一 致 性 要 求 不 高 的 场景 。 


` 写 降 级 : 比如， 秒杀 抢购 ， 我 们 可 以 只 进行 Cache 的 更 新 ， 然 后 异步 扣 
减 库存 到 DB， 保 证 最 终 一 任性 即 可 ， 此 时 可 以 将 DB 降级 为 Cache 。 


ERR: 在 大 促 活 动 时 ， 可 以 将 爬虫 流量 导向 静态 页 或 者 返回 空 数 
据 ， 从 而 保护 后 端 稀缺 资源 。 


风 控 降级 : 如 抢购 /秒杀 等 业务 ， 完 全 可 以 识别 机 器 人 、 用 户 画 像 或 者 
根据 用 户 风 控 级 别 进行 降级 处 理 ， 直 接 拒绝 高 风险 用 户 。 


52 ” 目 动 开 关 降 级 


自动 降级 是 根据 系统 负载 、 资 源 使 用 情况 、SLA 等 指标 进行 降级 。 
5.2.1 ”超时 降级 


当 访问 的 数据 库 /HTTP 服务 /远程 调用 啊 应 慢 或 者 长 时 间 响 应 慢 ， 且 该 服 
务 不 是 核心 服务 的 话 ， 可 以 在 超时 后 目 动 降级 。 比 如 ， 商 品 详情 页 上 有 
推荐 内 容 / 评 价 ， 但 是 ， 推 荐 内 容 / 评 价 暂 时 不 展示 ， 对 用 户 购物 流程 不 会 
产生 很 大 影响 。 对 于 这 种 服务 是 可 以 超时 降级 的 。 如 采 是 调用 别人 的 远 


程 服务 ， 则 可 以 和 对 方 定 义 一 个 服务 啊 应 最 大 时 间 ， 如 有 果 超 时 了 ， 则 有 目 


动 降级 。 


注意 ， 在 实际 场景 中 一 定 要 配置 好 超时 时 间 和 超时 重 试 次 数 及 机 制 ， 具 
体 细 市 请 参考 第 6 章 。 


5.2.2 ”统计 失败 次 数 降级 


有 时 依赖 一 些 不 稳定 的 API， 比 如 ， 调 用 外 部 机 票 服 务 ， 当 失败 调用 次 数 
达到 一 定 阐 值 自动 降级 (熔断 器 ; 。 然 后 通过 异步 线程 去 探测 服务 是 否 
恢复 了 ， 恢 复 则 取消 降级 。 


5.2.3 ”故障 降级 


比如 ， 要 调用 的 远程 服务 挂 掉 了 (网 络 故 障 、DNS 故 障 、HTTP 服 务 返 回 
错误 的 状态 码 、RPC 服 务 抛 出 异常 ) ， 则 可 以 直接 降级 。 降 级 后 的 处 理 
FRA: 默认 值 《比如 库存 服务 挂 了 ， 返 回 默认 现货 ) ^ BRAGE E 
如 广告 挂 了 了， 返回 提前 准备 好 的 一 些 静态 页 面 ) 、 缓 存 (之 前 暂 存 的 一 
些 缓存 数据 ) 。 


5.2.4” 限 流 降 级 


当 我 们 去 秒杀 或 者 抢购 一 些 限购 商品 时 ， 可 能 会 因为 访问 量 太 大 而 导致 
系统 毅 种 ， 此 时 ， 开 发 者 会 使 用 限 流 来 限制 访问 量 ， 当 达到 限 流 国 值 
时 ， 后 续 请 求 会 被 降级 。 降 级 后 的 处 理 方案 可 以 是 : 排队 页 面 (将 用 户 
导 流 到 排队 页 面 等 一 会 儿 重 试 ) 、 无 货 (直接 告知 用 户 没 货 了 ) 、 错 误 
页 (如 活动 太 火 爆 了 ， 稍 后 重 试 ) 。 


5.3 人工 开关 降级 


在 大 促 期 间 通 过 监控 发 现 线 上 的 一 些 服务 存在 问题 ， 这 个 时 候 需 要 暂时 
将 这 些 服 务 摘 掉 。 还 有 ， 有 时 通过 任务 系统 调用 一 些 服 务 ， 但 是 ， 服 务 
依赖 的 数据 库 可 能 存在 : 网 卡 打 满 了 、 数 据 库 挂 掉 了 或 者 很 多 慢 查 询 ， 
此 时 ， 需 要 暂停 任务 系统 让 服务 方 进行 处 理 。 还 有 发 现 突然 调用 量 太 
大 ， 可 能 需要 改变 处 理 方式 (比如 同步 转换 为 异步 。 此 时 可 以 使 用 开 
关 来 完成 降级 。 开 关 可 以 存放 到 配置 文件 、 数 据 库 、Redis/ZooKeeper 。 
如 有 果 不 是 存放 在 本 地 ， 则 可 以 定期 同步 开关 数据 〈 比 如 1 秒 同步 一 次 ) 。 
然后 ， 通 过 判断 某 个 key 的 值 来 决定 是 否 降级 。 


另外 ， 对 于 新 开发 的 服务 如 果 想 上 线 进 行 灰 度 测 试 ， 但 是 ， 不 太 确 定 该 
服务 的 逻辑 是 否 正 确 ， 此 时 ， 束 需要 设置 开关 ， 当 新 服务 有 问题 时 可 以 
通过 开关 切换 回 老 服 务 。 还 有 多 机 房 服务 ， 如 采 某 个 机 房 挂 控 了 ， 则 需 
ee Ld 


还 有 一 些 是 因为 功能 问题 需要 和 暂时 屏蔽 掉 某 些 功能 ， 比 如 ， 商 品 规格 参 
数 数据 有 问题 ， 数 据 问题 不 能 用 回 滚 解决 ， 此 时 需要 开关 控制 降级 。 


5.4” 读 服务 降级 


对 于 读 服务 降级 一 般 采 用 的 策略 有 : 和 暂时 切换 读 (降级 到 读 缓存 、 降 级 
ERSE) ` BIERO 《屏蔽 读 入 口 、 屏 蔽 茶 个 读 服务 ) 。 在 9.4.5 
五 中 将 介绍 读 服务 ， 即 接 入 层 缓存 ~ 应 用 层 本 地 缓存 ~ 分 布 式 缓存 
~RPC 服 务 /DB， 我 们 会 在 接 入 层 、 应 用 层 设 置 开 关 ， 当 分 布 式 缓存 、 
RPC 服 务 /DB 有 问题 时 目 动 降级 为 不 调用 。 当 然 ， 这 种 情况 适用 于 对 读 一 
致 性 有 要求 不 高 的 场景 。 


页 面 降 级 、 页 面 所 段 降级 、 页 面 异 步 请 求 降级 都 是 读 服务 降级 ， 目 的 是 
ZA PRIM (比如 ， 因 为 这 些 服务 也 要 使 用 核心 资源 ， 或 者 占 了 珊 宽 影响 
到 核心 服务 ) ， 或 者 因数 据 问题 暂时 屏蔽 。 


还 有 一 种 是 页 面 静态 化 场景 。 


动态 化 降级 为 静态 化 : 比如 ， 平 时 网 站 可 以 走动 态 化 泻 染 商品 详情 页 ， 
但 是 ， 到 了 大 促 来 临 之 际 可 以 将 其 切换 为 静态 化 来 减少 对 核心 资源 的 占 
用 ， 而 且 可 以 提升 性 能 。 其 他 还 有 如 列表 页 、 首 页 、 频 道 页 都 可 以 这 么 
处 理 。 可 以 通过 一 个 程序 定期 推送 静态 页 到 缓存 或 者 生成 到 磁盘 ， 出 问 
题 时 直接 切 过 去 。 

静态 化 降级 为 动态 化 : 比如 ， 当 使 用 静态 化 来 实现 商品 详情 页 架构 时 ， 
平时 使 用 静态 化 来 提供 服务 ， 但 是 ， 因 为 特殊 原因 静态 化 页 面 有 问题 
了 ， 和 需要 暂时 切换 回 动态 化 来 保证 服务 正确 性 。 


ot a eee ee anne 


5.5” 写 服务 降级 


写 服 务 在 大 多 数 场景 下 是 不 可 降级 的 ， 不 过 ， 可 以 通过 一 些 迁 回 战术 来 
解决 问题 。 比 如 ， 将 同步 操作 转换 为 异步 操作 ， 或 者 限制 写 的 量 /比例 。 


比如 ， 扣 减 库 存 一 般 这 样 操作 。 

方案 1 

扣 减 DB 库存 ， 扣 减 成 功 后 ， 更 新 Redis 中 的 库存 。 

方案 2 

扣 减 Redis 库 存 ， 同 步 扣 减 DB 库 存 ， 如 果 扣 减 失 败 ， 则 回 深 Redis 库 存 。 
前 两 种 方案 非常 依赖 DB， 假 设 此 时 DB 性 能 跟 不 上 ， 则 扣 减 库存 就 会 遇 到 
问题 。 因 此 ， 我 们 可 以 想到 方案 3: 扣 减 Redis 库 存 ， 正 常 同步 扣 减 DB 库 
存 ， 性 能 打 不 住 时 ， 降 级 为 发 送 一 条 扣 减 DB 库存 的 消息 ， 然 后 异步 进行 
DB 库存 扣 减 实现 最 终 一 致 即 可 。 

这 种 方式 发 送 扣 减 DB 库 存 消息 也 可 能 成 为 瓶颈 ， 这 时 可 以 考虑 方案 4: 


扣 减 Redis 库 存 ， 正 常 同步 扣 减 DB 库存 ， 性 能 打 不 住 时 降级 为 写 扣 减 DB 
oe 然后 本 机 通过 异步 进行 DB 库存 扣 减 来 实现 最 终 一 致 


也 就 是 说 ， 正 常情 况 下 可 以 同步 扣 减 库存 ， 在 性 能 打 不 住 时 ， 降 级 为 异 
步 。 另 外 ， 如 采 征 秒杀 场景 可 以 直接 降级 为 异步 ， 从 而 保护 系统 。 还 
有 ， 如 下 单 操作 可 以 在 大 促 时 暂时 降级 ， 将 下 单数 据 写 入 Redis， 然 后 等 
当然 也 有 更 好 的 解决 方案 ,但 是 更 复 洒 ,不 是 


还 有 如 用 户 评 价 ， 如 采 评 价 量 太 大 ， 那 么 也 可 以 把 评价 从 同步 写 降级 为 
异步 写 。 当 然 也 可 以 对 评价 按钮 进行 按 比 例 开 放 比如， 一些 人 看 不 到 
评价 操作 按钮 ) 。 比 如 ， 评 价 成 功 后 会 发 一 些 奖 励 ， 在 必要 的 时 候 降 级 
同步 到 异步 。 


5.6 ”多 级 降级 


缓存 是 离 用 户 越 近 越 高 效 ， 而 降级 是 离 用 户 越 近 越 对 系统 保护 得 好 。 
为 业务 的 复杂 性 导致 越 到 后 端 QPS/TPS 越 低 。 


页面 JS 降级 开关 : 主要 控制 页 面 功 能 的 降级 ， 在 页 面 中 ， 通 过 JS 脚本 
部 署 功能 降级 开关 ， 在 适当 时 机 开启 /关闭 开关 。 


` 接 入 层 降级 开关 : 主要 控制 请 求 入 口 的 降级 ， 请 求 进入 后 ， 会 首先 进入 
接 入 层 ， 在 接 入 层 可 以 配置 功能 降级 开关 ， 可 以 根据 实际 情况 进行 目 动 / 
人 工 降 级 。 这 个 可 以 参考 第 17 章 ， 尤 其 在 后 端 应 用 服务 出 问题 时 ， 通 过 
接 入 层 降级 从 而 给 应 用 服务 有 足够 的 时 间 恢 复 服务 。 


-应 用 层 降 级 开关 : 主要 控制 业务 的 降级 ， 在 应 用 中 配置 相应 的 功能 
关 ， 根 据 实际 业务 情况 进行 目 动 /人 工 降 级 。 


在 下 图 的 订单 履约 工作 流 中 ， 整 个 工作 流 可 以 进行 多 级 降级 。 


1. 如 采 亚 意 订 单 校 验 出 现 不 可 用 的 情况 ， 则 可 以 降级 ， 不 再 同步 进行 恶意 
校 验 ， 可 以 直接 绕 过 ， 也 可 以 改 成 异步 。 


2. 如 果 订 单 计 划 出 现 性 能 下 降 ， 但 还 可 以 处 理 ， 则 在 这 里 优先 处 理 高 优 级 
订单 、 处 理 逻 辑 较 简单 的 数据 〈 例 单 品 单 件 ) 。 


3. 分 发 订单 时 ， 如 果 仓 库 人 负载 饱 和 ， 则 可 以 降低 向 京东 库房 的 输送 量 ， 增 
大 其 他 目标 地 的 输送 量 。 


在 工作 流 中 的 每 一 个 流程 中 都 可 以 进行 相应 的 降级 ， 优 先 处 理 高 优先 级 
数据 、 只 处 理 某 些 特征 的 数据 、 合 理 分 配 流 量 到 最 需要 的 场合 。 上 述 内 
容 由 林 世 洪 提供 。 


更 多 降级 案例 可 扫 二 维 码 参考 肖 飞 在 2016 年 11 月 永 东 技术 开放 日 分 享 的 
《服务 降级 背后 的 技术 架构 设计 》。 


5.7 配置 中 心 


我 们 需要 通过 配置 方式 来 动态 开启 /关闭 降级 开关 ， 在 应 用 时 ， 首 先 要 封 
装 一 套 应 用 层 API 方 便 业 务 逻 辑 使 用 。 对 于 开关 数据 的 存储 ， 如 果 涉 及 的 
服务 器 /系统 较 少 ， 则 初期 可 以 考虑 使 用 配置 文件 进行 配置 。 如 采 涉 及 的 
服务 器 /系统 较 多 ， 则 应 该 使 用 配置 中 心 进行 配置 。 实 现时 要 做 到 不 需要 
修改 代码 ， 不 需要 重 局 应 用 即 可 动态 配置 开关 。 


5.7.1 应 用 层 API 封 装 

如 下 是 我 们 抽象 并 封装 的 开关 API 。 
USER( 

"用 户 信息 "， 


"user.not.call.backend", "是 否 不 调用 后 端 服务 "， 


"user.call.backend.rate.limit", "调用 后 端 服务 的 限 流 "， 
"user.redis.expire.seconds", "redis 绥 存 过 期 时 间 门 ， 
这 其 中 涉及 几 个 配置 。 


: user.not.call.backend: 是 否 回 源 调用 后 端 用 户 服 务 。 如 果 不 开 局 ， 那 么 
只 会 访问 缓存 ， 不 会 将 流量 打 到 后 端 。 


- user.call.backend.rate.limit: 调用 后 端 服 务 的 限 流 ， 比 如 配置 100， 即 一 
秒 只 


有 100 个 请 求 会 打 到 后 端 服务 ， 剩 余 请 求 如 果 缓 存 没 有 命中 时 ， 则 直 
接 返回 空 数据 或 错误 。 


- user.redis.expire.seconds: 后 端 返回 的 用 户 数据 在 缓存 中 缓存 多 和 久 。 
通过 封装 后 ， 我 们 可 以 很 简单 地 使 用 这 些 API © 

if (Switches.USER.notCall()) 
return null; 


{ 
} 


或 者 


cacheService.set(CacheKeys.getUserKey(pin), info, 


Switches.USER. getExpiresInSeconds()); 


API 实 现 是 从 配置 文件 获取 相关 配置 ， 如 果 没 有 ， 则 返回 一 个 默认 值 。 


public boolean notCall() { 


return DynamicConfigurer.getBoolean(callKey, false); 
} 


或 者 


public int getExpiresInSeconds() { 


return DynamicConfigurer.getInt(expiresKey, 


DEFAULT EXPIRES IN SECONDS); 
) 


5.7.2 ”使 用 配置 文件 实现 开关 配置 


使 用 properties 文 件 作 为 配置 文件 ， 借 助 JDK 7 WatchService 实 现 文件 变更 
监听 ， 实 现代 码 如 下 所 示 。 


static { 


try ( 
filename - "application.properties"; 


resource = new ClassPathResource (filename) ; 


// 监 听 filename 所 在 目录 下 的 文件 修改 、 删 除 事 件 


FileSystems.getDefault().newWatchService(); 


watchService - 
Paths.get(resource.getFile().getParent()) 


.register(watchService, 
StandardWatchEventKinds.ENTRY MODIFY, 


StandardWatchEventKinds.ENTRY DELETE); 
properties = PropertiesLoaderUtils.loadProperties(resource); 


} catch (IOException e) (e.printStackTrace();) 

// 启 动 一 个 线程 监听 内 容 变化 ， 并 重新 载 入 配置 

Thread watchThread = new Thread(() 
while (true) { 


try { 
WatchKey watchKey = watchService.take(); 
{ 


for (WatchEvent<?> event : watchKey.pollEvents()) 
if (Objects.equal(event.context().toString(), 
filename)) { 


=> { 


properties - 
PropertiesLoaderUtils.loadProperties (resource); 


break; 


watchKey.reset(); 


) catch (Exception e) (e.printStackTrace();] 


ks 
watchThread.setDaemon(true); 


watchThread.start(); 
Runtime.getRuntime().addShutdownHook(new Thread(() -> ( 


try { 
watchService.close(); 
) catch (IOException e) (e.printStackTrace();] 


))); 


- 使 用 WatchService 监 听 “application.properties” 文 件 所 在 目录 内 容 的 变化 ， 
包括 修改 、 删 除 事件 。 


通过 后 台 线 程 实现 阻塞 等 待 内 容 变 化 事件 ， 一 旦 发 现 有 内 容 变更 ， 如 采 
是 “application.properties” 文 件 发 生变 更 ， 则 重新 装载 配置 文件 。 


.JVM 停 止 时 记得 关闭 WatchService。 


整体 实现 比较 简单 ， 然 后 就 可 以 封闭 properties 实 现 目 己 的 开关 API 了 “。 通 
过 配置 文件 实现 开关 配置 的 方式 的 缺点 是 每 次 配置 文件 内 容 变更 都 需要 
将 配置 文件 同步 到 服务 右上 ， 这 点 算是 比较 麻烦 的 ， 如 果 目 动 部 署 系 统 
支持 动态 更 改 配 置 文件 并 同步 用 这 种 方式 ， 那 么 也 并 不 磋 烦 。 只 是 如 果 
要 维护 多 个 项 目 时 ， 则 需要 切换 多 个 界面 来 操作 。 


5.7.3 ”使 用 配置 中 心 实现 开关 配置 


使 用 统一 配置 中 心 ， 或 者 叫 分 布 式 配置 中 心 ， 目 的 是 实现 配置 开关 的 集 
中 管理 ， 要 有 配置 后 台 方 便 开 关 的 配置 ， 对 于 一 般 公 司 来 说 配置 中 心 的 
维护 要 简单 ， 不 需要 投入 过 多 的 人 力 来 做 这 件 事 情 。 配 置 中 心 不 管 是 采 
用 拉 取 模式 还 是 推送 模式 ， 要 考虑 到 连接 数 和 网 络 融 宽 可 能 带 来 的 风险 
和 问题 。 目 前 有 一 些 开 源 方案 可 以 选择 ， 如 ZooKeeper、Diamond、 
Disconf、Etcd 3、Consul。 本 文选 择 使 用 Consul， 其 支持 多 数据 中 心 、 服 
务 发 现 、KV 存 储 等 特性 ， 而 且 使 用 简单 ， 提 供 了 简单 的 Web UD EE 
理 ， 更 多 介绍 可 以 参考 Nginx 人 负载 均 衡 部 分 。 我 们 借助 Consul 的 KV 存储 特 
性 来 实现 配置 管理 。 


启动 Consul Server 与 HTTP API CRUD 一 样 即 可 。 


./consul agent -server -bootstrap-expect 1 -data-dir /tmp/consul -bind 0.0.0.0 
-client 0.0.0.0 — -ui-dir ./ui/ 


HTTP API CRUD 


E 新 增 / 修 改 
curl -X PUT -d 


true'http://localhost:8500/v1/kv/item  tomcat/user.not.call.backend 


cul -X PUT -d '30 http://localhost:8500/v1/kv/item tomcat  / 
user.redis.expire.seconds 


配置 。 

` 查询 某 个 开关 

curl http://localhost:8500/v1/kv/item_tomcat/user.not.call.backend 
` 查询 某 个 系统 的 开关 

curl http://localhost:8500/v1/kv/item_tomcat?recurse 


通过 添加 recurse 参 数 实现 日 录 树 递归 查询 ， 可 以 得 到 如 下 结 


[{"LockIndex":0,"Key":"item_tomcat/user.not.call.backend","Flags":0,"V 
alue":"ZmFsc2U=","CreateIndex":13009,"ModifyIndex":13192}, 
{"LockIndex":0, 


Weis 


"Key":"item tomcat/user.redis.expire.seconds","Flags":0," Value":"MzA=","C 
reateIndex":13015,"ModifyIndex":13144}] 


:阻塞 查询 某 个 系统 的 开关 


curl "http://192.168.61.129:8500/v1/kv/item tomcat?t-10s&recurse- 
true&index =13192" 


此 处 的 ipdex 取 列表 ModifyIndex 的 最 大 值 ， 当 其 中 的 修改 值 大 于 此 index， 
则 返回 数据 。 也 可 以 添加 “wait=10s” 设 置 超时 时 间 ， 超 时 后 阻塞 返回 。 


删除 茶 个 开关 


curl -X DELETE 
http://localhost:8500/v1/kv/item tomcat/user.not.call.backend 


.删除 某 个 系统 开关 
curl -X DELETE http://localhost:8500/v1/kv/item  tomcat?recurse 


整体 使 用 比较 简单 ，Consul Web UI 提供 了 可 视 化 配置 ， 在 局 动 时 ， 通 过 
ui-dir 指 定 下 载 的 Web UI 目录 即 可 ， 配 置 界面 如 下 图 所 示 。 


ITEM_TOMCAT/ + 


© 192.168.61.129:8500/ui/#/dc1/kv/item_tomcat/user.not.call.backend/edit 


a user.not.call.backend 


user.redis.expire.seconds 


配置 界面 十 分 简洁 ， 


false 


CANCEL DELETE 


目前 存在 的 一 个 缺点 是 没有 配置 项 的 描述 功能 ， 在 


定义 配置 时 ， 要 起 一 个 好 理解 且 清晰 的 名 字 。 
接 下 来 就 需要 在 应 用 代码 中 引入 配置 中 心 了 ， 代 码 如 下 所 示 。 


private static transient Properties properties = null; 
private static transient String system - "item tomcat"; 
static ( 
Consul consul = Consul.builder() 
.withHostAndPort (HostAndPort.fromString("192.168.61.129:8500")) 
.WithConnectTimeoutMillis (1000) 
.WithReadTimeoutMillis(30 * 1000) 
.wWithWriteTimeoutMillis (5000) .build(); 
final KeyValueClient keyValueClient = consul. keyValueClient (); 
final AtomicBoolean needBreak = new AtomicBoolean (true) ; 
Thread thread = new Thread(() -> { 
BigInteger index = BigInteger. ZERO; 
while(true) { 
Properties properties = new Properties (); 
try { 
// 阻 塞 获 取 item tomcat 下 的 数据 (阻塞 30 秒 )， 
//indexjÉitem tomcat 下 的 最 后 修改 数据 的 修改 index, 为 了 实现 阻塞 ， 
// 此 处 阻塞 时 间 受 readTimeoutMillis 影响 
List<Value> values = keyValueClient.getValues(system, 
QueryOptions.blockSeconds(30, index).build()); 
for(Value value : values) ( 
 properties.put( 
value.getKey().substring(system.length() + 1), 
value.getValueAsString() .orNull()); 
// 获 取 最 大 的 一 个 最 后 修改 index, 
// 实 现 KeyValueClient #getValues 的 阻塞 访问 
index = index.max( 
BigInteger.valueOf(value. getModifyIndex())); 


} 
properties = properties; 
} catch (ConsulException e) { 
e.printStackTrace(); 
if(e.getCode() == 404) ( // 如 果 key 不 存在 ， 则 休眠 
try { Thread.sleep(5000L); } catch (Exception el) {} 
} 
} 
if(needBreak.get() == true) {break; } 
} 
)); 
thread. run ();V// 先 运行 一 次 
needBreak.set(false); 
thread.setDaemon (true); 
thread.start(); 
} 


- 在 配置 Consul 时 ， 目 前 我 们 使 用 的 是 IPPORT， 实 际 应 用 时 建议 使 用 域 
名 /VIP， 记 得 配置 相关 的 超时 时 间 。 


: KeyValueClient 在 获取 数据 时 使 用 拉 取 模式 〈 长 轮 询 ) ， 可 以 设置 合理 
的 阻塞 时 间 〈 此 时 间 受 限于 Consul 配 置 的 超时 时 间 ) ， 选 择 最 大 的 
ModifyIndex 进 行 阻 塞 等 待 。 

- 当 ConsulException 的 code=404 表 示 system 在 配置 中 心 没 有 任何 配置 。 


ee 然后 启动 后 台 线 程 阻 塞 拉 取 最 新 配 


Consu 的 一 个 缺点 是 无 法 进行 增 量 配置 更 新 ， 如 有 果 订 阅 配置 的 应 用 很 多 ， 
那么 每 次 配置 更 新 的 下 发 量 就 非常 大 ， 如 果 有 增 量 配置 更 新 的 话 ， 则 只 
需要 把 变化 的 进行 下 发 。 


到 此 集成 Consul 配 置 中 心 束 完成 了 ， 此 处 只 列 出 了 核心 代码 ， 还 有 一 些 异 
常情 况 需要 大 家 处 理 ， 使 得 配置 中 心 在 应 用 中 做 到 高 可 用 。 


在 第 3 章 中 的 “使 用 Hystrix 实 现 隔离 ”部 分 我 们 已 经 介绍 了 Hystrix 的 作用 ， 


也 通过 Hystrix 实 现 了 线程 隔离 和 信和 号 量 隔离 ， 本 部 分 将 介绍 使 用 Hystrix 
实现 降级 和 熔断 。 


5.8 ”使 用 Hystrix 实 现 降级 


通过 配置 中 心 可 以 进行 人 工 降 级 ， 而 我 们 也 需要 根据 服务 的 超时 时 间 进 
行 目 动 降级 ， 本 部 分 将 演示 使 用 Hystrix 实 现 超时 目 动 降 级 。Hystrix 的 介 
绍 请 参考 第 3 章 中 的 Hystrix 人 简介 部 分 。 


public class GetStockServiceCommand extends HystrixCommand<String> { 
private StockService stockService; 
public GetStockServiceCommand(StockService stockService) { 
super(setter()); 
this.stockService - stockService; 
) 
private static Setter setter() { 
// 服 务 分 组 
HystrixCommandGroupKey groupKey = 
HystrixCommandGroupKey.Factory. asKey("stock"); 


// 命 令 配置 
HystrixCommandProperties.Setter commandProperties = 
HystrixCommandProperties.Setter() 
.wWithExecutionIsolationStrategy (HystrixCommandProperties. 
ExecutionIsolationStrategy. THREAD) 
.withFallbackEnabled (true) // 默 认为 true 


// 默 认为 10 
.WithFallbackIsolationSemaphoreMaxConcurrentRequests (100) 
// 默 认为 false 
.withExecutionIsolationThreadInterruptOnFutureCancel (true) 
// 默 认为 true 


.WithExecutionIsolationThreadInterruptOnTimeout (true) 
.WithExecutionTimeoutEnabled(true) // 默 认为 true 
.withExecutionTimeoutInMilliseconds (1000)// 默 认为 1000 


return HystrixCommand.Setter 
.withGroupKey (groupKey) 
.andCommandPropertiesDefaults (commandProperties); 


} 


GOverride 

protected String run() throws Exception { 
// 可 以 通过 抛 出 异常 ， 或 Thread.sleep 模拟 超时 
return stockService.getStock(); 

} 

@Override 

protected String getFallback() {// 降 级 方法 
return "Afi"; 

} 

} 


整体 执行 流程 如 下 图 所 示 。 


Command . 


一 一 请 求 一 >| PEN run() 
| 
所 一 响 应 一 | | Y 
= getFallback() 


首先 ，Command 会 调用 run 方 法 ， 如 果 run 方 法 超时 或 者 抛 出 异常 ， 且 局 用 
了 降级 处 理 ， 则 调用 getFallback 方 法 进行 降级 。 


而 降级 处 理 主 要 进行 两 部 分 处 理 : HystrixCommandProperties 配 置 和 
getFallback 降 级 处 理 方法 。 首 先 ， 我 们 看 一 下 HystrixCommandProperties 
配置 。 


: withFallbackEnabled : 是 否 启用 降级 处 理 ， 如 果 启 用 了 ， 则 在 超时 或 
异常 时 调用 getFallback 进 行 降级 处 理 ， 默 认为 开局。 


- withFallbackIsolationSemaphoreMaxConcurrentRequests: fallback 方 法 
的 信号 量 配置 ， 配 置 getFallback 方 法 并 发 请 求 的 信号 量 ， 如 果 请 求 超过 了 
并 发 信号 量 限 制 ， 则 不 再 尝试 调用 getFallback 方 法 ， 而 是 快速 失败 ， 默 认 
信号 量 为 10。 


: withExecutionIsolationThreadInterruptOnFutureCancel: [ij A S NE A 
THREAD 时 ， 当 执行 线程 执行 超时 时 ， 有 是否 进行 中 断 处 理 ， 即 


Future#cancel(true) 处 理 ， 默 认为 false。 


- withExecutionIsolationThreadInterruptOnTimeout: 当 隔 离 策 略为 
THREAD 时 ， 当 执行 线程 执行 超时 时 ， 是 否 进行 中 断 处 理 ， 默 认为 true。 


: withExecutionTimeoutEnabled: 是否 启用 执行 超时 机 制 ， 默 认为 tue 。 


- withExecutionTimeoutInMilliseconds: ”执行 超时 时 间 ， 默 认为 1000 喀 
Bb, UR 命令 & UE SIS B , HE 
executionIsolationThreadInterruptOnTimeout=true， 则 执行 线程 将 执行 中 断 
处 理 。 如 果 命 令 是 信号 量 隔 离 ， 则 进行 终止 操作 ， 因 为 信号 量 隔离 与 主 
线程 是 在 一 个 线程 中 执行 ， 其 不 会 中 断 线程 处 理 ， 所 以 要 根据 实际 情况 
来 决定 是 否 采用 信和 号 量 隔 离 ， 尤 其 涉及 网 络 访问 的 情况 。 


当 开局 了 降级 处 理 ，run 方 法 超时 或 者 异常 时 将 会 调用 getFallback 处 理 ， 
使 用 getFallback 时 需要 注意 以 下 几 点 。 


- 其 最 大 并 发 数 受 fallbackIsolationSemaphoreMaxConcurrentRequests 控 制 |， 
因此 ， 如 果 失 败 率 非常 高 ， 则 要 重新 配置 该 参数 ， 如 有 果 最 大 并 发 数 超 了 
该 配置 ， 则 不 会 再 执行 getFallback , m © Be xk Ww. MH 


如 “HystrixRuntimeException: GetStockServiceCommand fallback execution 
rejected" HF ft ° 


该 方法 不 能 进行 网 络 调用 ， 应 该 只 是 缓存 的 数据 ， 或 者 静态 数据 (如 我 
们 的 库存 方法 返回 有 货 ) 。 


` 如 果 必 须 走 网 络 调用 ， 则 应 该 在 getFallback 方 法 中 调用 另 一 个 Command 
实现 ， 通 过 Command 可 以 有 降级 和 熔断 机 制 保护 应 用 ， 而 getFallback 只 有 
fallbackIsolationSemaphoreMaxConcurrentRequests 参 数控 制 最 大 并 发 数 。 
在 使 用 Command 的 业务 代码 处 ， 可 以 使 用 如 下 方法 获取 执行 的 状态 。 
-isResponseTimedOut: ”响应 是 否 超 时 了 。 
isFailedExecution: 执行 是 否 失败 了 ， 如 抛 出 了 腊 负 
E 


: getFailedExecutionException: 获取 失败 后 的 执行 
HUE e 


-isResponseFromFallback: ”是否 是 getFallback 返 回 的 啊 应 。 


常 ， 即 run 方 法 抛 出 


5.9 ”使 用 Hystrix 实 现 熔 上 断 
5.9.1 ”熔断 机 制 实现 


Hystrix 提 供 了 熔断 实现 ， 炊 断后 会 目 动 降级 处 理 ， 如 下 图 所 示 。 


command | 


HystrixCircuitBreaker 
allowRequest 


true 
v 
Command Command 
run getFallback 


Command 首 先 调用 HystrixCircuitBreakerfallowRequest 判 断 是 否 熔断 了 ， 
如 果 没 有 熔断 ， 则 执行 Command#run 方 法 正和 党 处理， 如果 熔 断 了 ， 则 直 
接 调 用 Command# getFallback 方 法 降级 处 理 o 


接 下 来 ， 我 们 看 一 下 HystrixCircuitBreakerImpl# allowRequest 方 法 的 实 
现 。 


public boolean allowRequest() { 
// 如 果 熔 断 开 关 强制 打开 ， 则 熔断 降级 处 理 
if (properties.circuitBreakerForceOpen().get()) { 
return false; 
) 
// 如 果 熔 断 开 关 强制 团 合 ， 则 正常 处 理 
if (properties.circuitBreakerForceClosed().get()) { 

// 还 是 需要 调用 isopen 方法 进行 采样 处 理 

isOpen(); 

return true; 

) 
// 正 常 判断 
return !isOpen() || allowSingleTest(); 
) 
// 人 允许 在 一 个 时 间 窗 口内 进行 单 次 访问 测试 
public boolean allowSingleTest() { 
// 熔 断 开 关 打 开 时 ， 最 后 一 次 测试 时 间 
long timeCircuitOpenedOrWasLastTested =circuitOpenedOrLastTestedTime. get () ; 
// 如 果 熔 断 开 关 处 于 打开 状态 ， 
// 且 在 一 个 时 间 窗 口内 (circuitBreakerSleepWindowInMilliseconds)， 
// 则 人 允许 一 次 访问 进行 测试 
if (circuitOpen.get() && 

System.currentTimeMillis() » 
timeCircuitOpenedOrWasLastTested + 
properties.circuitBreakerSleepWindowInMilliseconds().get()) ( 

if (circuitOpenedOrLastTestedTime. 
compareAndSet (timeCircuitOpenedOrWasLastTested, 
System.currentTimeMillis())) ( 


return true; 


) 


return false; 


QOverride 
public boolean isOpen() { 
// 如 果 熔 断 开 关 处 于 打开 状态 ， 则 熔断 降级 处 理 
if (circuitOpen.get()) { 
return true; 


) 


// 熔 断 开 关 当 前 处 于 闭合 状态 ， 需 要 根据 采样 判断 当前 是 否 需要 熔断 
HealthCounts health = metrics.getHealthCounts(); 
// 如 果 当 前 采样 的 总 请 求 数 小 于 circuitBreakerRequestVolumeThreshold 阀 值 ， 


// 则 不 进行 熔断 
if (health.getTotalRequests() < 
properties.circuitBreakerRequestVolumeThreshold(). get()) { 


return false; 
} 
// 如 果 当 前 采样 的 错误 率 小 于 circuitBreakerErrorThresholdPercentage IW, 
// 则 不 进行 熔断 
//errorPercentage = errorCount / totalCount * 100 
if (health.getErrorPercentage() < 
properties. circuitBreakerErrorThresholdPercentage().get()) { 
return false; 
) else ( 
// BURWELL TEL, BEAT HTT RA eh BE 
if (circuitOpen.compareAndSet (false, true)) { 
circuitOpenedOrLastTestedTime 
.Set (System. currentTimeMillis()); 
return true; 
} else { 
return true; 


} 


当 我 们 的 熔断 开关 处 于 打开 状态 时 ， 此 时 是 不 允许 处 理 任 何 请 求 的 ， 而 
是 直接 降级 处 理 ， 但 是 提供 了 markSuccess 方 法 ， 当 请 求 处 理 成 功 时 进行 
熔断 开关 闭合 。 


public void markSuccess() { 
if (circuitOpen.get()) { 


if (circuitOpen.compareAndSet(true, false)) { 
// 重 置 health 采样 ， 不 影响 其 他 采样 


metrics.resetStream(); 


) 


iH circuitBreakerSleepWindowInMilliseconds n] 以 控制 一 个 时 间 窗 口内 可 
进行 一 次 请 求 测试 ， 如 果 测 试 成 功 ， 则 闭合 熔断 开关 ， 否则 还 是 打开 状 
仿 ， 从 而 实现 了 快速 失败 和 快速 恢复 。 


关于 熔断 开关 需要 知道 如 下 几 个 概念 


` 闭合 (Closed) : 如 果 配 置 了 熔断 开关 强制 闭合 ， 或 者 当前 请 求 失败 率 
没有 超过 失败 率 冰 值 ， 则 熔断 开关 处 于 闭合 状态 ， 不 局 动 炊 断 机 制 ， 即 
不 进行 降级 处 理 。 


.打开 (Open) : 如 果 配 置 了 熔断 开关 强制 打开 ， 或 者 当前 失败 率 超过 
失败 率 靖 值 ， 则 熔断 开关 打开 ， 局 动 熔断 机 制 ， 根 据 配置 调用 降级 处 理 
方法 getFallback 进 行 降级 处 理 。 


半 打 开 (Half-Open) : 当 熔 断 处 于 打开 状态 后 ， 不 能 一 直 熔 断 下 去 ， 
需要 在 一 个 时 间 窗 口 后 进行 重 坛 ， 这 种 状态 就 是 半 打 开 。Hystrix 人 允许 在 
circuit BreakerSleepWindowInMilliseconds f 口内 进行 一 次 重 试 ， 重 试 成 功 
则 闭合 熔断 开关 ， 否 则 熔断 开关 还 是 处 于 打开 状态 。 


S oy 样 的 请 求 被 认为 是 错误 呢 ，HealthCounts 在 统计 错误 数量 时 使 用 如 
IKA 


public HealthCounts plus(long[] eventTypeCounts) { 
long updatedTotalCount - totalCount; 
long updatedErrorCount - errorCount; 


long successCount = egntTypeCounts [HystrixEventType.SUCCESS. ordinal(]; 
long failureCount -eventTypeCounts [HystrixEventType.FAILURE. ordinal(]; 
long timeoutCount = egntTypeCounts [HystrixEventType. TIMEOUT. ordinal(]; 
long threadPoolRejectedCount - 
eventTypeCounts[HystrixEventType. THREAD POOL REJECTED.ordinal()]; 
long semaphoreRejectedCount - 
eventTypeCounts[HystrixEventType. SEMAPHORE REJECTED.ordinal()]; 


updatedTotalCount += (successCount + failureCount + timeoutCount 十 
threadPoolRejectedCount + semaphoreRejectedCount); 


updatedErrorCount += (failureCount + timeoutCount 十 
threadPoolRejectedCount + semaphoreRejectedCount); 


return new HealthCounts (updatedTotalCount, updatedErrorCount); 


即 拓 败 (如 异常 》、 超 时 、 线程 池 拒绝 、 信 号 量 拒 绝 数 最 总 和 是 失败 总 
5.9.2 ”配置 示例 


下 面 是 HystrixCommandProperties 的 熔断 参数 配置 。 


HystrixCommandProperties.Setter commandProperties - 
HystrixCommandProperties. Setter() 

.withCircuitBreakerEnabled (true) // 默 认为 rue 
.withCircuitBreakerForceClosed (false) // 默 认为 false 
.withCircuitBreakerForceOpen (false) //EKWW false 
.withCircuitBreakerErrorThresholdPercentage (50) //EKUA 50$ 
.withCircuitBreakerRequestVolumeThreshold(20) // 默 认为 20 
.withCircuitBreakerSleepWindowInMilliseconds (5000) // 默 认为 5s 


具体 配置 合 义 如 下 所 示 。 


- withCircuitBreakerEnabled: 是 否 开 启 炊 断 机 制 ， 默 认为 true » 


. withCircuitBreakerForceClosed: ”是否 强制 关闭 炊 断 开关 ， 如 果 强 制 天 
闭 了 熔断 开关 ， 则 请 求 不 会 被 降级 ， 一 些 特殊 场景 可 以 动态 配置 该 开 
关 ， 默 认为 false ° 


: withCircuitBreakerForceOpen: 是 否 强制 打开 熔断 开关 ， 如 果 强 制 打 
开 了 熔断 开关 ， 则 请 求 强制 降级 调用 getFallback 处 理 ， 可 以 通过 动态 配置 
来 打开 该 开关 实现 一 些 特殊 需求 ， 默 认为 false 。 


- withCircuitBreakerErrorThresholdPercentage : 如 果 在 一 个 采样 时 间 窗 
OÑ, 失败 率 超 过 该 配置 ， 则 自动 打开 熔断 开关 实现 降级 处 理 ， 即 快速 
失败 。 默 认 配 置 下 采样 周期 为 10s， 失 败 率 为 50%。 


: withCircuitBreakerRequestVolumeThreshold: 在 熔断 开关 闭合 的 情况 
下 ， 在 进行 失败 率 判 断 之 前 ， 一 个 采样 周期 内 必须 进行 至 少 N 个 请 求 才 
能 进行 采样 统计 ， 目 的 是 有 足够 的 采样 使 得 失败 率 计 算 正 确 ， 默 认为 
20 ° 


- withCircuitBreakerSleepWindowInMilliseconds: Xii Ja HJ E Hh [8] d 
口 ， 且 在 该 时 间 窗 口内 只 允许 一 次 重 试 。 即 在 熔断 开关 打开 后 ， 在 该 时 
间 窗 口 允 许 有 一 次 重 试 ， 如 采 重 试 成 功 ， 则 将 重 置 Health 采 样 统计 并 闭合 
熔断 开关 实现 快速 恢复 ， 否 则 熔断 开关 还 是 打开 状态 ， 执 行 快速 失败 。 

- 熔断 后 将 降级 调用 getFallback 进 行 处 理 (fallbackEnabled=true) ， 通 过 
Command 如 下 方法 可 以 判断 是 否 熔 断 了 。 


isCircuitBreakerOpen : 熔断 开关 是 否 打 开 [f , K 
过 *circuitBreakerForceOpen().get() || (!circuitBreakerForceClosed().get() && 
circuitBreaker.isOpen())"74]lBr ° 


- isResponseShortCircuited :  isCircuitBreakerOpen-true , H 调用 
getFallback 时 返回 true 。 


5.9.3 ”采样 统计 
Hystrix 在 内 存 中 存储 采样 数据 ， 支 持 如 下 三 种 采样 。 


: BucketedCounterStream: 计数 统计 ， 比 如 记录 一 定时 间 窗 口内 的 失 
败 、 超 时 、 线 程 池 拒 绝 、 信 号 量 拒绝 数量 ， 记 录 N 组 。 写 入 数据 时 写 到 
第 N 组 ， 统 计时 使 用 前 N -1 组 数据 ， 因 为 第 N 个 刚 开 始 统计 时 是 随时 变化 
的 。 然 后 基于 时 间 滚 转 采 样 分 组 即 可 。 


成 功 | a || 2 || 3 |] 10 |] 15| 1 || 2 || 3 || 10 || 15 
失败 | | 10 || 8 |} 10 |) o |} o ||10|| 8 || 10 |] O || O 
超时 | | 1 |] 1 |] 0 |] o fo |] 1 jf] 2 |] o lo |] o 
线程 拒绝 | | 0 00 0 | 0 0 0 0 o || 0 


采样 统计 滚 转 时 间 窗口 为 10s， 每 秒 1 个 分 组 ( 桶 ) ， 即 每 秒 采样 一 次 ， 
每 个 分 组 记录 着 当前 桶 的 成 功 、 失 败 、 超 时 、 线 程 拒绝 统计 数量 。 


` RollingConcurrencyStream : 最 大 并 发 数 统计 ， 如 Command/ThreadPool 
的 最 大 并 发 数 。 


- RollingDistributionStream: 延 时 百分比 统计 ， 同 HystrixRollingNumber 
类 似 ， 差 别 在 于 其 是 百 分 位 数 的 统计 。 比 如 每 组 记录 P (比如 100) 个 数 
值 ， 统 计时 使 用 前 N -1 组 数据 ， 将 分 组 内 数据 按 从 小 到 大 排序 ， 然 后 累 
加 ， 处 于 第 p AMENA Ep 百 分 位 数 ， 通 过 它 可 以 实现 P50、P99、 
P999, ，Hystrix 用 来 统计 时 延 的 分 布 情况 。 最 新 版 本 Hystrix 使 用 
HdrHistogram 库 来 实现 统计 。 


1.Command、ThreadPool 计 数 /最 大 并 发 采样 统计 


HystrixThreadPoolProperties.Setter threadPoolProperties - 
HystrixThreadPoolProperties.Setter() 


.withMetricsRollingStatisticalWindowInMilliseconds (1000) 
.withMetricsRollingStatisticalWindowBuckets (10); 


HystrixCommandProperties.Setter commandProperties - 
HystrixCommandProperties. Setter() 


.withMetricsRollingStatisticalWindowInMilliseconds (10000) 
.withMetricsRollingStatisticalWindowBuckets (10); 


- withMetricsRollingStatisticalWindowInMilliseconds: ”配置 采样 统计 深 
转 时 间 窗 口 ， 默 认为 10s 。 

- withMetricsRollingStatisticalWindowBuckets: ”配置 采用 统计 深 转 时 间 
窗口 内 的 桶 的 总 数量 ， 上 默 认为 10， 比 如 时 间 窗 口 为 10000， 桶 数量 为 10， 
则 采样 统计 间隔 为 每 秒 一 个 桶 统计 。 


2.Command 健 康 度 采 样 统计 


HystrixCommandProperties.Setter commandProperties - 


HystrixCommandProperties. Setter() 
.withMetricsRollingStatisticalWindowInMilliseconds (10000) 
.withMetricsHealthSnapshotIntervalInMilliseconds (500); 


- withMetricsRollingStatisticalWindowInMilliseconds: 同上 所 示 。 


withMetricsHealthSnapshotIntervalInMilliseconds: ”记录 健康 采用 统计 
的 快照 频率 ， 默 认为 500ms， 即 500ms 一 个 采样 统计 间隔 ， 那 么 桶 的 数量 
为 10000/500=20 个 。 


该 统计 在 熔断 机 制 中 使 用 ， 如 有 果 计 算 熔 断 的 频率 非常 高 ， 则 要 控制 好 采 
样 的 频率 ， 如 果 太 频繁 ， 那 么 将 造成 CPU 计 算 密 集 ， 如 10ms 一 个 周期 ， 
因为 会 对 前 N -1 个 桶 进行 统计 ， 计 算 素 加 时 会 耗费 CPU“。 所 以 选择 Hystrix 
要 注意 此 处 的 性 能 消耗 和 调 优 。 如 有 果 此 处 是 性 能 瓶 筑 ， 则 可 以 废 掉 统 
计 ， 或 者 按照 Hystrix 思 路 实现 目 己 的 降级 组 件 。 


3.Command 时 延 分 布 采样 统计 


HystrixCommandProperties.Setter commandProperties - 
HystrixCommandProperties.Setter() 


.withMetricsRollingPercentileWindowInMilliseconds (60000) 
.withMetricsRollingPercentileWindowBuckets (6) ; 


同 withMetricsRollingStatisticalWindowInMilliseconds 和 
withMetricsRollingStatistical WindowBuckets ， 默 认 采 样 深 转 时 间 窗 口 为 
60s， 总 共 6 个 桶 ， 即 采样 统计 间隔 为 每 10 秒 一 个 桶 统计 。 

4. 统 计 结 果 


可 以 调 用 Command#getMetrics 获取 采样 统计 ， 然 后 通过 
HystrixCommandMetrics 相 关 方 法 获取 统计 数据 。 


getExecutionTimePercentile(50);//P50 
getExecutionTimePercentile(99);//P99 


getExecutionTimePercentile(999);//P999 


也 可 以 订阅 Deere ae getInstance() 进 行 统 计 。Hystrix 提 供 了 
hystrix-dashboard 进 行 图 形 化 展示 。 


接 下 来 我 们 通过 Turbine + Hystrix-Dashboard 实 现 集群 化 的 统计 可 视 化 。 


Hystrix 
App 


Hystrix 
App 


Hystrix 
App | 


Turbine 
Aggregate | 


Hystrix 
Dashboard | 


首先 ，Hystrix 应 用 会 暴露 统计 接口 ， 然 后 Turbine 会 聚合 这 C RN 
Hystrix Dashboard 会 拉 取 聚合 后 的 统计 信息 并 展示 到 仪表 一 


5.Hystrix 客 户 问 添加 暴露 统计 信息 Servlet 


QBean 


public ServletRegistrationBean servletRegistrationBean() { 
return new ServletRegistrationBean( 
new HystrixMetricsStreamServlet(), "/hystrix.stream"); 


) 


在 我 们 的 Hystrix 客 户 端 添 加 如 上 spring-boot 代 码 配 置 ， 然 后 就 可 以 访问 如 
http://127.0.0.1:9080/hystrix.stream 获取 到 统计 数据 。 


6. 部 署 Turbine 


下 载 Turbine WAR 包 (本文 使 用 的 是 Turbine 1.0.0) ， 部 署 到 Tomcat 中 ， 
然后 修改 WEB-INF/classes/config.properties 配 置 ， 启 动 Tomcat ° 


turbine.ConfigPropertyBasedDiscovery.default.instances=127.0.0.1 


turbine.instanceUrlSuffix=:9080/hystrix.stream 


配置 Hystrix 应 用 的 IP 和 获取 统计 信息 的 URL path 部 分 ， 组 合 后 拉 取 统计 信 
J, o W Pl Whttp://127.0.0.1:8080/turbine/turbine.stream 获取 聚合 后 的 统计 数 


据 。 
7. 部 署 Hystrix Dashboard 


下 载 hystrix-dashboard WAR 包 (本文 使 用 的 是 hystrix-dashboard 1.5.6) ， 
部 署 到 Tomcat 中 ， 然 后 启动 Tomcat。 访 问 如 http://127.0.0.1:8080/hystrix- 


dashboard A INEA: ° 
在 如 下 界面 添加 要 监 控 的 Turpine 地 址 ， 然 后 进入 仪表 盘 束 可 以 看 到 统计 


信 im ° 


Hystrix Dashboard 


Eureka URL: 
Eureka Application: |Choose here v Stream Type: Hystrix Turbine * 


http://localhost:8080/turbine/turbine.stream| 


Cluster via Turbine (default cluster): http://turbine-hostname:port/turbine. stream 
Cluster via Turbine (custom cluster): http://turbine-hostname:port/turbine. stream?cluster- 
[clusterName] 

Single Hystrix App: http://hystrix-app:port/hystrix. stream 


Delay: ms Title: 


Authorization: 


Add Stream | 


Hystrix Stream: http://127.0.0.1:8080/turbine/turbine.stream 


Circuit Sort: Error then Volume |Alphabetical | Volume | Error | Mean | Median | 90 | 99 | 99.5 


getStock 
2.0 % 


| Host: 42.0/s 
Cluster: 42.0/s 
Circuit Closed 


Hosts 1 90th Oms 
Median Oms 99th Oms 
Mean Oms 99.5th Oms 


Thread Pools Sort: Alphabetical | Volume | 
stock-pool 
Host: 179.0/s 
Cluster: 179.0/s 
Active Max Active 


0 1 
Queued 0 Executions 179 
Poal Size 5 Queue Size 10 


6 超时 与 重 试 机 制 
6.1 简介 


在 实际 开发 过 程 中 ， 笔 者 见 过 太 多 故障 是 因为 没有 设置 超时 或 者 设置 得 
不 对 而 造成 的 。 而 这 些 故 障 都 是 因为 没有 意识 到 超时 设置 的 重要 性 而 造 
成 的 。 如 果 应 用 不 设置 超时 ， 则 可 能 会 导致 请 求 啊 应 慢 ， 慢 请 求 票 积 导 
致 连锁 反应 ， 甚 至 造成 应 用 雪 衣 。 而 有 些 中 间 件 或 者 框架 在 超时 后 会 进 
行 重 试 (如 设置 超时 重 试 两 次 ) ， 读 服务 天 然 适 合 重 试 ， 但 写 服务 大 多 
不 能 重 试 (如 写 订 单 ， 如 果 写 服务 是 窜 等 的 ， 则 重 试 是 允许 的 ) ， 重 试 
次 数 太 多 会 导致 多 倍 请 求 流量 ， 即 模拟 了 DDoS 攻击 ， 后 果 可 能 是 灾难 ， 
因此 ， 务 必 设 置 合 理 的 重 试 机 制 ， 并 且 应 该 和 熔断 、 人 快速 失败 机 制 配 
合 。 在 进行 代码 Review 时 ， 一 定 记 得 Review 超 时 与 重 试 机 制 。 


本 章 主要 从 Web 应 用 和 服务 化 应 用 的 角度 出 发 介绍 如 何 设置 超时 与 重 试 
(系统 层面 的 超时 设置 在 这 里 没有 涉及 ) ， 而 Web 应 用 需要 在 如 下 链条 中 
设置 超时 与 重 试 机 制 。 


浏览 器 /Web 客 户 端 


1. 域名 解析 2. 发 起 请 求 


负载 均衡 负载 均衡 
Nginx Nginx 


Web 容 器 Web 容 器 
Tomcat Tomcat 


JDBC 客 户 端 JDBC 客 户 端 


SOA 客 户 端 SOA 客 户 端 
HTTP 客 户 端 HTTP 客 户 端 


HTTP 服 务 


从 上 图 来 看 ， 在 整个 链条 中 的 每 一 个 点 都 要 考虑 设置 超时 与 重 斌 机制。 
而 其 中 最 重要 的 超时 设置 是 网 络 连接 / 读 / 写 的 超时 时 间 设 置 。 


下 面 将 按照 如 下 分 类 进行 超时 与 重 试 机 制 的 讲解 。 


. 代理 层 超时 与 重 试 : 如 Haproxy、Nginx、Twemproxy， 这 些 组 件 可 实现 
代理 功能 ， 如 Haproxy 和 Nginx 可 以 实现 请 求 的 负载 均衡 。 而 Twemproxy 可 
以 实现 Redis 的 分 厂 代 理 。 需 要 设置 代理 与 后 端 真 实 服 务 器 之 间 的 网 络 连 
接 / 读 / 写 超时 时 间 。 


. Web 容 器 超时 : ”如 Tomcat、Jetty 等 ， 提 供 HTTP 服 务 运行 环境 的 ， 需要 
设置 客户 端 与 容器 之 间 的 网 络 连 接 / 读 / 写 超时 时 间 ， 和 在 此 容器 中 默认 
Socket 网 络 连 接 / 读 / 写 超时 时 间 。 


数据 库 
MySQL 


. 中 间 件 客户 端 超时 与 重 试 : 如 JSF (京东 SOA 框 架 ) 、Dubbo、JMQ 
(京东 消息 中 间 件 ) 、CXF、Httpclient 等 ， 需 要 设置 客户 的 网 络 连 接 / 读 / 

写 超 时 时 间 与 失败 重 试 机 制 。 

.数据库 客 户 端 超时 : 如 MySQL ^ Oracde, ， 需 要 分 别 设置 JDBC 

Connection 、Statement 的 网 络 连 接 / 读 / 写 超时 时 间 ， 事务 超时 时 间 ， 获 取 

连接 池 连 接 等 待 时 间 o 


.NoSQL 客 户 端 超时 : 如 Mongo、Redis， 需 要 设置 其 网 络 连 接 / 读 / 写 超时 
时 间 ， 获 取 连 接 池 连接 等 待 时 间 。 


.业务 超时 : 如 订单 取消 任务 、 超 时 活动 关闭 ， 还 有 如 通 
Future#get(timeout, unit) 限 制 某 个 接口 的 超时 时 间 。 


.前端 Ajax 超时 ， 浏览 器 通过 Ajax 访问 时 的 网 络 连 接 / 读 / 写 超时 时 间 。 
从 如 上 分 类 可 以 看 出 ， 其 中 最 重要 的 超时 设置 是 网 络 相 关 的 超时 设置 。 


6.2 ”代理 层 超 时 与 重 试 


对 于 代理 层 我 们 以 Nginx 和 Twemproxy 案 例 来 讲解 。 首 先 ， 看 一 下 Nginx 的 
相关 超时 设置 。 


6.2.1 Nginx 


Nginx 主 要 有 4 类 超时 设置 : 客户 端 超时 设置 、 DNS 解析 超时 设置 、 代 理 
超时 设置 ， 如 果 使 用 ngx_lua， 则 还 有 Lua 相 关 的 超时 设置 。 


1. 客 户 端 超时 设置 


对 于 客户 端 超时 主要 设置 有 读 取 请 求 头 超时 时 间 、 读 取 请 求 体 超时 时 
间 、 发 送 响应 超时 时 间 、 长 连接 超时 时 间 。 通 过 客户 端 超时 设置 避免 客 
ir a E 影响 服务 器 端的 可 处 
理 能 


- client header timeout time: 设置 读 取 客户 端 请 3: “六 超时 时 [B], BUA 
60s, ， 如 果 在 此 超时 时 间 内 客户 端 没 有 发 送 完 请 求 头 ， 则 啊 应 408 
(Request Time-out) 状态 码 给 客户 端 。 


cc 


: client body. timeout time: 设置 读 取 客 户 端 内 容 体 超时 时 间 ， 默 认为 
60s， 此 超时 时 间 指 的 是 两 次 成 功 读 操作 间隔 时 间 ， 而 不 是 发 送 整个 请 求 
体 的 超时 时 间 ， 如 果 在 此 超时 时 间 内 容 户 端 没有 发 送 任何 请 求 体 ， 则 响 
应 408 (Request Time-out) 状态 码 给 客户 端 。 


-send_timeout time: 设置 发 送 啊 应 到 客户 端的 超时 时 间 ， 默 认为 60s， 
此 超时 时 间 指 的 也 是 两 次 成 功 写 操作 间隔 时 间 ， 而 不 是 发 送 整 个 啊 应 的 
， 。 如 果 在 此 超时 时 间 内 窗户 端 没 有 接收 任何 啊 应 ， 则 Nginx 关 闭 
此 连接 。 


- keepalive timeout timeout [header timeout]: 设置 HTTP 长 连接 超时 时 
则 。 其 中 ， 第 一 个 参数 timeout 是 各 百 诉 Nginx 长 连接 超时 时 间 古 多 少 ， 默认 
为 75s。 第 二 个 参数 header timeout 用 于 设置 啊 应 头 “Keep-Alive: 
timeout-time" , 2 告知 客户 端 长 连接 超时 时 间 。 两 个 参数 可 以 不 一 
FÉ, “Keep-Alive: timeout=time” 啊 应 头 可 以 在 Mozila 和 Konqueror 系 列 浏 
哆 絮 中 起 作用 ， 而 MSIE 长 连接 默认 大 约 为 60s， 而 不 会 使 用 “Keep-Alive: 
timeout-time" ° 如 Httpclient 框 架 会 使 用 Pra -Alive: timeout=time” 啊 应 头 
的 超时 (如 果 不 设置 默认 ， 则 认为 是 永久 ) 。 如 果 timeout 设 置 为 0， 则 表 
示人 禁用 长 连接 。 


此 参数 要 配合 keepalive disable 和 keepalive requests 一 起 使 用 。 
keepalive_disable 表 示人 禁用 哪些 浏 换 器 的 长 连接 ， 默 认 值 为 msie6， 即 禁 
一 些 老 版 本 的 MSIE 的 长 连接 文 持 。keepalive_requests 参 数 的 作用 是 一 个 
客户 端 可 以 通过 此 长 连接 的 请 求 次 数 ， 默 认为 100。 


首先， 浏览 絮 在 请 求 时 会 通过 如 下 请 求 尖 告 知 服务 器 是 否 支 持 长 连接 。 


Y Request Headers view source 
Accept text/html,application/xhtml«xml,app 
Accept-Encoding: gzip, deflate, sdch 
a — zh- ICON diage 8.8 


Connection: keep-alive 


http/1.0 默 认 是 关闭 长 连接 的 ， 需 要 添加 HITP 请 求 头 “Connection: keep- 
alive" 才 能 启用 。 而 http/1.1 默 认 启 用 长 连接 ， 需 要 添加 HTTP 请 求 
头 “Connection: close” 进 行 关闭 。 


接着 ， 如 果 Nginx 设 置 keepalive_timeout 5s, JI] XJ vi, ae SU BI EL P Ri] py 
3L. o 


Response Headers view source 
Cache-Control: max-age-864688 


下 图 是 Wireshark 抓 包 ， 可 以 看 到 后 两 次 请 求 没 有 三 次 握手 。 


quU W 


q=1 Ack=2 Win=262 


54 1744-80 [ACK] Seq=1 Ack=1 Win=65536 Len=0 
24 GET /img/1. jpg HTTP/1.1 

60 80-1744 [ACK] Seqel Acke471 win=30336 Len=0 
87 HTTP/1.1 304 Not Modified 


: mg/L. Jp P/l. 
287 HTTP/1.1 304 NOT Modified 
54 1744-80 [ACK] Seq=941 Ack=467 Win=65024 Len=0 


如 果 Nginx 设 置 keepalive_timeout 10s 10s, MA spas SUFI AT KM bk © 


¥ Response Headers view source 
Cache-Control: max-age=86460 


54 2765-80 [FIN, ACK] Seq=1 


2 0.00040200192.168.61.1 192.168.61.129 TCP 66 3053-80 [SYN] seq=0 win- 
3 0.00110900 192.168.61.129 192.168.61.1 TCP 60 80-2765 [ACK] Seq=1 Ack= 
4 0.00110900 192.168. 61.129 192.168. 61.1 TCP 66 80-3053 [SYN, ACK] Seq=0 
5 0. 00116700 192.168. 61.1 192.168. 61.129 TCP 54 3053-80 [ACK] seq-1 Ack- 
6 0. 00193500 192.168. 61.1 192.168. 61.129 HTTP 524 GET /img/1. jpg HTTP/1.1 

7 0.00211100 192.168.61.129 192.168.61.1 TCP 60 80-3053 [ACK] seg-1 Ack=| 
8 0.00311100 192.168. 61.129 192.168.61.1 HTTP 311 HTTP/1.1 304 Not Modifie 
9 0.20024200192.168.61.1 192.168.61.129 TCP 54 3053-80 [ACK] seq=471 Ac 
NE 61.129 192.168.61.1 TCP 60 80-3053 ÉL 
26 10.0131060 192.168.61.1 192.168.61.129 TCP 54 3053-80|[ACK] Seq=#71 Ac 


QUE Nginxix &keepalive timeout 75s 30s ° 


如 下 是 Chrome 浏 览 器 的 Wireshark 抓 包 。 在 45s 时 ，Chrome 发 送 了 TCP 
Keep-Alive 来 保持 TCP 连 接 。 在 57s 时 ， 浏 览 器 又 发 出 了 一 次 请 求 。 而 在 
132s 时 ，Nginx 发 出 了 FIN 来 关闭 连接 (75s 后 连接 超时 了 ) ° 


1 0.00000000 192.168.61.1 192.168.61.129 TCP 66 10949-80 [SYN] Seq-0 win-8192 Len-0 MSS-1460 wS-256 SA 
2 0.00070400 192.168.61.129 192.168.61.1 TCP 66 80-10949 [SYN, ACK] Seq-0 Ack-1 win-29200 Len-0 MSS-14 
3 0.00075700 192.168. 61.1 192.168.61.129 TCP 54 10949-80 [ACK] Seq-1 Ack=1 win-65536 Len=0 

4 0.00304100 192.168.61.1 192.168.61.129 HTTP 524 GET /img/1.jpg HTTP/1.1 

5 0.00370300 192.168.61.129 192.168.61.1 TCP 60 80-10949 [ACK] Seq-1 Ack-471 win-30336 Len=0 

6 0.00370300 192.168. 61.129 192.168.61.1 HTTP 311 HTTP/1.1 304 Not Modified 


Seq=471 Ack-258 win=65280 Len-0 SLE-1 S 


19 57.5168670 192. 168. 61.129 192.168.61.1 
20 57.5168680 192.168.61.129 192.168.61.1 
21 57.7152340 192.168. 61.1 192.168. 61.12€ 


; ; :61.129 92.168.61. P x Seq=515 Ack=941 win=31360 Len=0 
33|132.593141 192. 168. 61. E! 192.168.61.129 TCP 54 10949-80 ACK] Seq=941 Ack=516 win=65024 Len=0 


eee 在 请 求 后 65 秒 左右 时 ， 浏 览 器 重 置 了 连 


-168B.01.129 19Z7.1068.61.1 TCF 1514 segment or a reassembled PDUJ 
98 2; 14816500 192.168.61.129 192.168.61.1 HTTP 143 HTTP/1.1 200 OK (image/jpeg) 
99 2.14817400 192.168.61.1 192.168.61.129 TCP 54 11884-80 [ACK] Seq-582 Ack-110166 win-49548 Len=0 
OU 2.14832100 192.168.61.1 192.168.61.129 TCP 54 Dn MID —— 11884-80 [ACK] Seq=582 Ack-110166 win-65 


1-582 Ack-110166 Win=0 Len=0 


可 以 看 出 不 同 浏览 器 的 超时 处 理 方 式 不 一 样 ， 而 HITP 了 响应 头 “Keep- 
Alive: timeout=30” 对 Chrome 和 IE 都 没有 起 作用 。 


接着 ， 如 果 Nginx 设 置 keepalive_timeout 0， 则 浏览 器 会 收 到 如 下 啊 应 头 。 


Y Response Headers view source 
Cache-Control: max-age-86488 


ngin into 

bb 1443-80 [SYN] Seq=0 win-5192 Len-U MSS=146U WS-255 SACK PERM 
66 80-1443 [SYN, ACK] Seq-0 Ack=1 win-29200 Len=0 MS 
54 1443-80 [ACK] Seq-1 Ack=1 win=65536 Len=0 
324 GET /img/1. jpg HTTP/1.1 
60 80-1443 [ACK] Seq=1 Ack=471 win=30336 Len=0 
482 HTTP/1.1 304 Not Modified 
60 80-1443 [FIN, ACK] Seq=229 Ack=471 win=30336 Len-0 
54 1443-80 [ACK] Seq=471 Ack=230 win=65280 Len=0 
M POSER ee ACK] Seq=471 Ack=230 win=65280 Le 


=1 
5-1460 SACK PERM 


66 1476-80 = 

66 80-1476 [SYN, 

54 1476-80 [ACK] Seq-1 Ack-1 win=65536 Len=0 
p24 GET /img/1.jpg HTTP/1.1 

60 80-1476 [ACK] Seq=1 Ack-471 win=30336 Len=0 


P82 HTTP/1.1 304 Not Modified 

60 80-1476 [FIN, ACK] Seq=229 Ack-471 win-30336 Len=0 

54 1476-80 [ACK] Seq-471 Ack-230 win=65280 Len=0 

54 1476-80 ime ace) Seq=471 Ack=230 win=65280 Len=0 
Ack=472 win-30336 


对 于 客户 端 超时 设置 ， 要 根据 实际 场景 来 决定 。 如 果 是 短 连 接 服务 ， 则 
可 以 考虑 将 时 间 设置 得 短 一 些 ， 如 果 是 文件 上 传 ， 则 需要 考虑 设置 得 长 
一 些 。 另 外 ， 笔 者 见 过 很 多 人 对 长 连接 没有 正确 配置 ， 建 议 配置 完成 后 
通过 抓 包 查看 长 连接 是 否 起 作用 。 keepalive_timeout 和 keepalive_requests 
E UOTIS 只 要 其 中 一 个 到 达 设 置 的 国 值 ， 连 接 就 会 被 
关闭 。 


2.DNS 解 析 超 时 设置 


resolver timeout 30s: 设置 DNS 解析 超时 时 间 ， 默 认为 308。 其 配合 
resolver address ...[valid- time] 进 行 DNS 域名 解析 。 当 在 Nginx 中 使 用 域名 
P, Lus 要 考虑 设置 这 文 两 个 参数 。 在 Nginx 社 区 版 中 采用 如 下 配置 。 


upstream backend { 
server c0.3.cn; 


server cl.3.cn; 


如 上 两 个 域名 会 在 Nginx 解 析 配 置 文件 的 阶段 被 解析 成 耳 地 址 并 记录 到 
upstream 上 ， 当 这 两 个 域名 对 应 的 IP 地 址 发 生变 化 时 ， 该 upstream 不 会 被 
更 新 。 而 Nginx 商 业 版 是 支持 动态 更 新 的 。 


一 种 简单 的 办 法 是 使 用 如 下 方式 ， 每 次 都 会 动态 解析 域名 ， 这 种 情况 在 
多 域名 情况 下 比较 麻烦 ， 实 现 不 优雅 。 


location /test { 
proxy pass http://60.3.on; 
} 


如 果 使 用 OpenResty， 则 可 以 通过 Lua 库 lua-resty-dns 进 行 DNS 解析 。 


local resolver = require "resty.dns.resolver" 
local r, err = resolver:new{ 
nameservers = ("8.8.8.8", ("8.8.4.4", 53} }, 
retrans = 5, -- 5 retransmissions on receive timeout 


timeout = 2000, -- 2 sec 


} 
当 使 用 Nginx 1.5.8、1.7.4 遇 到 以 下 代码 时 ， 
could not be resolved(110:Operation timed out); 
或 者 
wrong ident 37278 response for *** jd.local, expected 33517 
unexpected response for *** jd.local 


可 能 是 遇 到 了 如 下 了 BUG ( http//nginx.org/enCHANGES-1.6 ^ 
http://nginx.org/en/ 


CHANGES-1.8). 


Bugfix: requests might hang if resolver was used and a timeout 
occurred during a DNS request. 


请 考虑 升级 到 Nginx 1.6.2、1.7.5 或 者 在 Nginx 本 机 部 署 dnsmasq 提 升 DNS 解 
析 性 能 。 


3. 代 理 超时 设置 
Nginx 配 置 如 下 所 示 。 


upstream backend server { 
server 192.168.61.1:9080 max fails-2 fail timeout-10s weight=1; 
server 192.168.61.1:9090 max fails-2 fail timeout-10s weight-1; 
} 


server { 


location /test { 
proxy connect timeout 5s; 
proxy read timeout 5s; 
proxy send timeout 5s; 


proxy next upstream error timeout; 
proxy next upstream timeout 0; 
proxy next upstream tries 0; 


proxy pass http://backend server; 
add header upstream addr Supstream_addr; 


) 


backend_server 定 义 了 两 个 上 游 服务 器 192.168.61.1:9080 (返回 hello); 和 
192.168.61.1:9090 (返回 hello2) ° 


如 上 指令 主要 有 三 组 配置 : 网 络 连 接 / 读 / 写 超时 设置 、 失 败 重 试 机 制 设 
置 、upstream 存 活 超时 设置 。 


Q 网 络 连接 / 读 / 写 超时 设置 


: proxy. connect, timeout time: 与 后 端 / 上 游 服 务 器 建立 连接 的 超时 时 
间 ， 默 认为 60s， 此 时 间 不 超过 75s。 


. proxy_read_timeout time: 设置 从 后 端 / 上 游 服务 圳 读 取 响应 的 超时 时 
间 ， 默 认为 60s， 此 超时 时 间 指 的 是 两 次 成 功 读 操 作 间 隔 时 间 ， 而 不 是 读 
取 整 个 响应 体 的 超时 时 间 ， 如 果 在 此 超时 时 间 内 上 游 服务 恬 没 有 发 送 任 
何 响应 ， 则 Nginx 关 闭 此 连接 。 


: proxy. send, timeout time: |. ix E ftn Ym/ EE 5 a8 A XS VB OK ERI] PT 
间 ， 默 认为 60s， 此 超时 时 间 指 的 是 两 次 成 功 写 操作 间隔 时 间 ， 而 不 是 发 
送 整个 请 求 的 超时 时 间 ， 如 果 在 此 超时 时 间 内 上 游 服 务 恬 没有 接收 任何 
响应 ， 则 Nginx 关 闭 此 连接 o 


对 于 内 网 高 并 发 服务 ， 请 根据 需要 调整 这 几 个 参数 ， 比 如 内 网 服务 TP999 
为 1s， 可 以 将 连接 超时 设置 为 100~500ms， 而 读 超 时 可 以 为 1.5~3s 左 右 。 


Q 失败 重 试 机 制 设置 


* proxy next upstream error | timeout | invalid header | http 500 | 
http 502 | ht tp 503 | http. 504 |http. 403 | http 404 | non idempotent | off 

配置 什么 情况 下 需要 请 求 下 一 台 上 游 服 务 器 进行 重 试 。 默 认为 “error 
timeout”。error 表 示 与 上 游 服务 器 建立 连接 、 写 请 求 或 者 读 啊 应 头 出 钳 。 
timeout 表 示 与 上 游 服 务 器 建立 连接 、 写 请 求 或 者 读 啊 应 头 超 时 。 
invalid_header 表 示 上 游 服 务 咒 返回 空 的 或 错误 的 响应 头 。http_XXX 表 示 
上 游 服务 器 返回 特定 的 状态 码 。 non_idempotent 表 示 RFC-2616 定 义 的 AEF 
等 HTTP 方 法 (POST ` LOCK ^ PATCH) ， 也 可 以 在 失败 后 重 试 下 一 台 上 
游 服 务 器 ( 即 默 认 窜 等 方法 GET、HEAD ` PUT ` DELETE ` OPTIONS ` 
TRACE 才 可 以 重 试 ) 。off 表 示 禁 用 重 试 。 


poo COS 因此 ， 需 要 如 下 两 个 指令 控制 重 试 次 数 和 重 试 超 
时 时 间 e 


- proxy. next upstream tries number: 设置 重 试 次 数 ， 默 认 0 表 示 不 限 
制 , M d (包括 第 一 次 和 之 后 的 重 试 次 
数 之 和 ) 。 


proxy next upstream timeout time: 设置 重 试 最 大 超时 时 间 ， 默 认 0 表 
示 不 限制 。 


即 在 proxy_next_upstream_timeout 时 间 内 人 允许 proxy_next_upstream_tries 次 
重 试 。 如 果 超 过 了 其 中 一 个 设置 ， 则 Nginx 也 会 结束 重 试 并 返回 客户 端 响 
应 〈 可 能 是 错误 码 ) o 

如 下 配置 表示 当 error/timeout 时 重 斌 upstream 中 的 下 一 台 上 游 服务 颖 ， 如 


果 重 试 的 总 时 间 超 过 6s 或 者 重 试 了 1 次 ， 则 表示 重 试 失 败 (因为 之 前 已 经 
请 求 一 次 了 ， 所 以 还 能 重 试 1 次 ) ，Nginx 结 束 重 试 并 返回 客户 端 响 应 。 


proxy next upstream error timeout; 
proxy. next upstream timeout 6s; 


proxy next upstream, tries 2; 


G upstream 存 活 超 时 设置 


-max_fails 和 fail_timeout: ”配置 什么 时 候 Nginx 将 上 游 服 务 器 认定 为 不 可 
用 /不 存活 。 当 上 游 服 务 器 在 fail_timeout 时 间 内 失败 了 max_fails 次 ， 则 认 
为 该 上 游 服务 器 不 可 用 /不 存活 。 并 在 接 下 来 的 fail_timeout 时 间 内 从 
upstream 摘 掉 该 节点 〈 即 请 求 不 会 转发 到 该 上 游 服 务 器 ) 。 


什么 情况 下 被 认定 为 失败 呢 ? 其 由 proxy_next_upstream 定 义 ， 不 过 ， 不 
管 proxy_next_upstream 如 何 配置 ，error timeout 和 invalid_header 都 将 被 认 
为 是 失败 。 


如 server 192.168.61.1:9090 max. fails-2 fail_timeout=10s; 表 示 在 10s 内 如 果 
失败 了 2 次 ， 则 在 接 下 来 的 10s 内 认定 该 节点 不 可 用 /不 存活 。 这 种 存活 检 
测 机 制 只 有 当 访 问 该 上 游 服务 器 时 ， 采 取 惰 性 检查 ， 才 可 以 使 用 
ngx_http_upstream_check_module 配 置 主动 检查 。 


max_fails 设 置 为 0 表示 不 检查 服务 器 是 否 可 用 〈 即 认为 一 直 可 用 ) ， 如 果 
upstream 中 仪 镜 一 台 上 游 服 务 嚣 ， 则 该 服务 器 是 不 会 被 摘除 的 ， 将 从 不 被 
认为 不 可 用 。 

@ ngx_lua 超 时 设置 


当 我 们 使 用 ngx_lua 时 ， 也 应 考虑 设置 如 下 网 络 连 接 / 读 / 写 超 时 。 


lua socket connect timeout 100ms; 
lua socket send timeout 200ms; 


lua socket read timeout 500ms; 
在 使 用 Lua 时 ， 我 们 会 按照 如 下 策略 进行 重 试 。 


if (status -- 502 or status -- 503 or status -- 504) and request time « 
200 then 
resp = capture(proxy uri) 
status - resp.status 
body = resp.body 
request time = request time + tonumber(var.request time) * 1000 
end 


即 如 果 状 态 码 是 500/502/503/504， 并 且 该 次 请 求 耗 时 在 200ms 以 内 ， 则 我 
们 进行 一 次 重 试 。 


6.2.2 Twemproxy 


Twemproxy 是 Twitter 开源 的 Redis 和 Memcache 代 理 中 间 件 ， 其 目的 是 减少 
与 后 端 缓存 服务 器 的 连接 数 。 


n 表示 与 后 端 服 务 磊 建 立 连 接 、 接 收 啊 应 的 超时 时 间 ， 稚 认 永 不 
HH o 


server retry timeout 和 server_failure_limit: 当 开 局 auto_eject_hosts , 
FU i Jet AS is AT FANT B Sipa T 点 并 在 一 定时 间 后 进行 重 试 。 
server failure limit 设 置 连续 失败 多 少 次 后 将 节点 临时 摘除 ， 
server_retry_timeout 设 置 摘除 节点 后 等 E eu TE, 从 而 保证 不 永久 
性 地 将 节点 摘除 。 


6.3 ”Web 容器 超时 


笔者 的 生产 环境 用 的 Java Web 容 器 是 Tomcat， 本 部 分 将 以 Tomcat 8.5 作 为 
例子 进行 讲解 。 

-connectionTimeout: 配置 与 客户 端 建立 连接 的 超时 时 间 ， 从 接收 到 连 
接 后 ， 在 配置 的 时 间 内 没有 接收 到 客户 端 请 求 行 ， 将 被 认定 为 连接 超 
时 ， 默 认为 60000 (60s) 。 

-socket.soTimeout: 从 客户 端 读 取 请 求 数据 的 超时 时 间 ， 默 认同 


connectionTimeout，NIO 和 NIO2 支 持 该 配置 。 


-asyncTimeout: Servlet 3 异步 请 求 的 超时 时 间 ， 默 认为 30000 (30s) 。 


disableUploadTimeout 和 connectionUploadTimeout : 当 配置 
disableUploadTimeout 为 false 时 (默认 为 tue ， 和 connectionTimeonut 一 
FÉ) ， 文 件 上 传 将 使 用 connectionUploadTimeout 作 为 超时 时 间 。 


- keepAliveTimeout 和 maxKeepAliveRequests: 和 Nginx 配 置 类 似 。 
keepAliveTimeout 默 认为 connectionTimeout ， 配 置 为 -1 表示 永 不 超时 。 
maxKeepAliveRequests 默 认为 100。 


6.4 ”中 间 件 客户 端 超时 与 重 试 


JSF 是 和 永 东 目 研 的 SOA 框 架 ， 主 要 有 三 个 组 件 ， 注册 中 心 、 服 务 提供 端 、 
服务 消费 端 。 


首先 是 在 服务 提供 端 /消费 端 与 注册 中 心 之 间 进 行 服务 注册 /发 现时 可 以 配 
置 timeout (调用 注册 中 心 超时 时 间 ， 默 认为 5s) 和 connectTimeout (连接 
注册 中 心 的 超时 时 间 ， 默 认为 20s) 


服务 提供 端 可 以 配置 timeout (服务器 端 调 用 超时 时 间 ， 默 认为 5s) 。 


服务 消费 端 可 以 配置 timeout 〈 调 用 端 调用 超时 时 间 ， 默 认为 5s) 
connectTimeout (建立 连接 超时 时 间 ， 默 认为 5s) ^ disconnectTimeout 
( 靳 开 连 接 / 等 得 结果 超时 时 间 ， 默 认为 10s) 、reconnect (调用 端 重 连 死 
亡 服务 器 端的 间隔 ， 配 置 小 于 0 表示 不 重 连 ， 默 认为 108) 、heartbeat ( 调 
用 端 往 服 务 器 端 发 心跳 包 的 间 隅 ， 配 置 小 于 0 代表 不 发 送 ， 默 认为 30s) 
和 retries 《失败 后 重 试 次 数 ， 默 认 0 不 重 试 ) 


Dubbo 也 有 类 似 的 配置 ， 在 此 就 不 性 述 了 。 


JMQ 是 京东 消息 中 间 件 ， 主 要 有 四 个 组 件 : 注册 中 心 、Broker (JMQ 的 服 
务 器 端 实例 ， 生 产 和 消费 消息 都 跟 它 交互 ) 、 和 生产 者 、 消 费 者 。 


首先 是 在 生产 者 /消费 者 与 Broker 进 行 发 送 /接收 消息 时 ， 可 以 配置 
connectionTimeout (连接 超时 ) ` sendTimeout (发 送 超时 ) 和 soTimeout 
( 读 超 时 ) 


生产 者 可 以 配置 retryTimes (发 送 失 败 后 的 重 试 次 数 ， 默 认为 2 次 ) 


消费 者 可 以 配置 pullTimeout (长 轮 询 超时 时 间 ， 即 拉 取 消 恩 超时 时 
间 ) 、maxRetrys (最 大 重 斌 次数， 对 于 消费 者 要 人 允许 无 限制 重 试 ， 即 一 
直 拉 取消 息 ) 、retryDelay ( 重 试 延 迟 ， 通 过 exponential 配 置 延 迟 增加 倍 
数 一 直 增加 到 maxRetryDelay) ^ maxRetryDelay (HRA HEIR) 。 消 费 
者 还 需要 配置 应 答 超时 时 间 《服务 器 端 需要 等 竺 客户 端 返 回应 答 才 能 移 
除 消 息 ， 如 果 没 有 应 答 返 回 ， 则 会 等 竺 应 答 超时 ， 在 这 段 时 间 内 锁定 的 
消息 不 能 被 消费 ， 必 须 等 竺 超时 后 才能 被 消费 ) 


对 于 消息 中 间 件 ， 我 们 在 实际 应 用 中 关注 超时 配置 会 少 一些 ， 因 为 生产 
者 默认 配置 了 重 试 次 数 ， 可 能 会 存在 重复 消息 ， 消 费 者 需要 进行 去 重 处 


He 


CXF 可 以 通过 如 下 方式 配置 CXF 客 户 端 连 接 超时 ` 等 待 响应 超时 和 长 连 
Ta © 


HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy(); 


httpClientPolicy.setConnectionTimeout(30000);//E 3A 7330s 
httpClientPolicy.setReceiveTimeout(60000); /默认 为 60s 


httpClientPolicy.setConnection(ConnectionType.KEEP_ALIVE);// 默 iA 为 
Keep-Alive 


((HTTPConduit)client.getConduit()).setClient(httpClientPolicy); 
Httpclient 4.2.x 可 以 通过 如 下 代码 配置 网 络 连接 、 等 竺 数据 超时 时 间 。 


HttpParams params = new BasicHttpParams(); 
/设置 连接 超时 时 间 


Integer CONNECTION_TIMEOUT = 2* 1000; /设置 请 求 超时 2s 


Integer SO_TIMEOUT = 2 * 1000; /设置 等 待 数据 超时 时 间 2s 


Long CONN MANAGER TIMEOUT =1L*1000; /定义 了 当 从 
/ClientConnectionManager 中 检索 ManagedClientConnection 
/实例 时 使 用 的 毫秒 级 的 超时 时 间 


params.setIntParameter( CoreConnectionPNames.CONNECTION TIMEOUT , 
CONNECTION TIMEOUT); 


params.setIntParameter(CoreConnectionPNames.SO TIMEOUT , 
SO TIMEOUT); 


/在 提交 请 求 之 前 ， 测 试 连接 是 否 可 用 


params.setBooleanParameter(CoreConnectionPNames.STALE CONNECTION 
CHECK , true) ; 


/这 个 参数 期 望 得 到 一 个 java.lang.Long 类 型 的 值 。 如 果 这 个 参数 没有 被 设 
E, 


/ 则 连接 请 求 就 不 会 超时 (无 限 大 的 超时 时 间 ) 


params.setLongParameter(ClientPNames.CONN MANAGER TIMEOUT s 
CONN MANAGER TIMEOUT); 


PoolingClientConnectionManager conMgr = new 
PoolingClientConnectionManager(); 


conMgr.setMaxTotal(200);// 设 置 最 大 连接 数 
/是 路 由 的 默认 最 大 连接 (该 值 默 认为 2) ， 限 制 数量 实际 使 用 


DefaultMaxPerRoute 
/而 非 MaxTotal 


/设置 过 小 ， 无 法 文 持 大 并 发 (ConnectionPoolTimeoutException: Timeout 
waiting 


//for connection from pool), E% Hz *}maxTotalA)ZH4> 
conMgr.setDefaultMaxPerRoute(conMgr.getMax Total()); 
/ (目前 只 有 一 个 路 由 ， 因 此 让 它 等 于 最 大 值 ) 
/设置 访问 协议 


conMgr.getSchemeRegistry().register(new Scheme(" http", 80, 
PlainSocketFactory. getSocketFactory ())); 


conMgr.getSchemeRegistry().register(new Scheme(" https", 443, 
SSLSocketFactory. getSocketFactory ())); 


httpClient - new DefaultHttpClient(conMgr, params); 
httpClient.setHttpRequestRetryHandler (new 
DefaultHttpRequestRetryHandler(0, false)); 


为 我 们 使 用 http connection 连接 池 ， 上 所 以 需要 配置 
CONN_MANAGER_TIMEOUT， 表 示 从 连接 池 获 取 http connection 的 超时 
时 间 。 


此 处 还 通 过 httpClient.setHttpRequestRetryHandler(new 
DefaultHttpRequestRetry Handler(0, false)) 配 置 了 请 求 重 试 策略 (默认 重 试 
3 次 ) 。 当 执行 请 求 遇 到 异常 时 ， 会 调用 retryRequest 来 判断 是 否 进 行 重 
试 ， 而 以 下 情况 不 会 进行 重 试 : 达到 重 试 次 数 、 服 务 器 不 可 达 、 连 接 被 
拒绝 、 连 接 终止 、 请 求 已 发 送 。 而 需 等 HITP 方 法 的 请 求 、 
reduestSentRetryEnabled=true 且 请 求 还 未 成 功 发 送 时 可 以 重 试 。 


如 果 响 应 503 错 误 状 态 码 ， 如 上 重 试 机 制 是 不 可 用 的 ， 则 可 以 考虑 使 用 
AutoRetryHttpClient 客 户 端 ， 其 可 以 配置 ServiceUnavailableRetryStrategy， 

默认 实现 为 DefaultServiceUnavailableRetryStrategy， 可 以 配置 重 试 次 数 
maxRetries 和 重 试 间隔 retryInterval。 每 次 重 试 之 前 都 会 等 待 retryInterval 毫 


秒 时 间 。 


假设 服务 由 多 个 机 房 提 供 ， 其 中 在 一 个 机 房 服 务 出 现 问题 时 ， 应 该 目 动 
切换 到 另 一 个 机 房 ， 可 以 考虑 使 用 如 下 方法 。 


public staticString g&(List«String» apis, Obect[] args, String emmuing, 
Header[] headers, Integer timeout) throws Exception { 
String response - null; 
for(String api : apis) { 
String uri = UriComponentsBuilder. fromHttpUrl (api) 
.buildAndExpand(args). toUriString(); 
response = HttpClientUtils 
.getDataFromUri(uri, encoding, headers, timeout); 
// 如 果 失 败 了 ， 重 试 一 次 
if (Objects.equal (response, HTTP ERROR)) { 
continue; 
} 
// 如 果 域 名 解析 失败 ， 重 试 
if(Objects.equal(response, HTTP UNKNOWN HOST ERROR)) { 
response = HTTP ERROR; // 调 用 方 根据 这 个 判断 是 否 有 问题 
continue; 
} 
if(Objects.equal(response, HTTP SOCKET TIMEOUT ERROR)) { 
response = HTTP ERROR; // 调 用 方 根据 这 个 判断 是 否 有 问题 
continue; 


return response; 


) 


return response; 


) 


iad 同 机 房 的 API 即 可 ， 当 其 中 一 个 不 可 用 时 目 动 重 试 另 一 个 机 房 
JAPI ° 


6.5 数据库 客户 端 超时 


在 使 用 数据 库 客 户 端 时 ， 我 们 会 使 用 数据 库 连 接 池 ， 数 据 库 连接 池 可 以 
进行 如 下 超时 设置 。 


<bean id="dataSource" 
class-"org.apache.commons.dbcp2.BasicDataSource" 
destroy-method-"close"» 
<!-- Statement 默认 超时 时 间 --> 
<property name-"defaultQueryTimeout" value="3"/> 


«1-- BOA Elo d PACA RACE socket Z/a: -- 
<property name-"connectionProperties" 
value="connectTimeout=2000; socketTimeout=2000 "/> 
«1-- BRE EAE AGE BIER EI, UTAKA, HMA 500ms --> 
<property name="maxWaitMillis" value="500" /> 
</bean> 


.网络 连接 / 读 超时 : 使 用 connectionProperties 配 置 MySQL 超 时 时 间 ， 如 果 
是 Oracle 则 可 以 通过 如 下 配置 。 


<property name="connectionProperties" 
value-"oracle.net.CONNECT TIMEOUT=2000; oracle. jdbc.ReadTimeout=2000"/> 
e 默认 Statement 超 时 时 间 ， A ey Tineo 单位 是 s。 

。 从 连接 池 获 取 连 接 的 等 待 时 间 ， 通 过 maxWaitMillis 配 置 。 

e ”Statement 超 时 ， 如 果 使 用 iBATIS， 则 可 以 通过 如 下 方式 配置 Statement 超 时 。 


<settings cacheModelsEnabled="false" enhancementEnabled="true" 
lazyLoadingEnabled="false" errorTracingEnabled="true" 
maxRequests="32" defaultStatementTimeout="2"/> 


defaultStatementTimeout 的 单位 是 s， 根 据 业 务 配置 。 如 果 配 置 了 数据 库 连 
接 池 ， 则 此 处 不 用 配置 。 


如 果 只 想 设 置 某 个 Statement 的 超时 时 间 ， 则 可 以 考虑 <insert ...... 


timeout="2"> ° 


如 上 配置 其 会 调用 Statement.setQueryTimeout 方 法 设置 Statement 超 
时 时 间 。 


.事务 超时 是 总 的 Statement 超 时 设置 ， 比 如 我 们 使 用 Spring 管理 事务 ， 可 
以 使 用 如 下 方式 配置 全 局 默认 的 事务 级 别 的 超时 时 间 。 


<bean id-"txManager" class="org.springframework.jdbc.datasource 
.DataSourceTransactionManager"> 
<property name="dataSource" ref="dataSource" /> 
<property name="defaultTimeout" value="3"/> 
</bean> 


这 里 我 们 分 析 为 什么 说 事务 超时 是 Statement 超 时 的 总 和 ， 此 处 我 们 分 析 
Spring 的 DataSourceTransactionManager, 首先 开启 事务 时 会 调用 其 
doBegin 方 法 。 


// 先 获取 Transactional € XM timeout, WRA, MEH defaultTimeout 

int timeout = determineTimeout (definition); 

if (timeout != TransactionDefinition.TIMEOUT DEFAULT) { 
txObject.getConnectionHolder().setTimeoutInSeconds (timeout); 


) 


rH determineTimeout H 来 犹 取 我 们 设置 的 事务 超时 时 间 ， 然 后 设置 到 
Conmecuonblolder 对 象 上 (其 是 ResourceHolder 子 类 ) ， 接 着 下 面 看 
ResourceHolderSupport 的 setTimeoutInSeconds 实 现 。 


public void setTimeoutInSeconds(int seconds) { 
setTimeoutInMillis (seconds * 1000); 


) 


public void setTimeoutInMillis(long millis) { 
this.deadline = new Date(System.currentTimeMillis() + millis); 


) 


大 家 可 以 看 到 ， 此 处 会 设置 一 个 deadline 时 间 ， 用 来 判断 事务 超时 时 间 ， 
那 什么 时 候 调 用 呢 ? 首先 检查 该 类 中 的 代码 : 


public int getTimeToLiveInSeconds() ( 
double diff = ((double) getTimeToLiveInMillis()) / 1000; 
int secs = (int) Math.ceil(diff); 


checkTransactionTimeout(secs <= 0); 
return secs; 


public longgetTimeToLiveInMillis() throws TrasactionTimedOutException( 
if (this.deadline == null) { 
throw new IllegalStateException("No timeout specified for t his 
resource holder"); 
} 
long timeToLive = this.deadline.getTime() - System.currentTimeMillis(); 
checkTransactionTimeout (timeToLive <= 0); 
return timeToLive; 


private void checkTransactionTimeout (boolean deadlineReached) 
throws TransactionTimedOutException { 
if (deadlineReached) { 
setRollbackOnly(); 
throw new TransactionTimedOutException("Transaction timed out: 
deadline was " + this.deadline) ; 


} 


/ 


我 们 发 现 调用 getTimeToLiveInSeconds 和 getTimeToLiveInMillis 会 检查 ET 
why, n SOosH Hp PS, uj bs dud s $8 Au |] S , HM 


TransactionTimedOutExceptiont 7$ 3117 [AIR ° 


d 


DataSourceUtils.apply Transaction Timeout 会 调 
DataSourceUtils.applyTimeout, Data SourceUtils.applyTimeout 的 代码 如 下 。 


public static void applyTimeout(Statement stmt, DataSource dataSource, 
int timeout) throws SQLException { 

ConnectionHolder holder = 

(ConnectionHolder) TransactionSynchronizationManager 

.getResource (dataSource); 

if (holder != null && holder.hasTimeout()) { 

// 计算 剩余 的 事务 超时 时 间 并 有 覆盖 Statement 超时 

stmt.setQueryTimeout (holder.getTimeToLiveInSeconds ()); 
) else if (timeout > 0) ( 

// 如 果 没 有 配置 事务 超时 ， 则 使 用 Statement 超时 


stmt.setQueryTimeout (timeout); 


在 执行 stmt.setQueryTimeout(holder.getTimeToLiveInSeconds()) H 4 W] FA 
getTimeTo LiveIn Seconds()， 这 会 检查 事务 是 否 超 时 。 在 JdbcTemplate 
中 ， 执 行 SQL 之 前 ， 会 调用 其 applyStatementSettings 方 法 ， 其 将 调用 
DataSourceUtils.applyTimeout(stmt,getDataSource(), getQueryTimeout()) 设 置 
超时 时 间 。 


此 处 有 一 个 问题 ， 如 果 设 置 了 事务 超时 ，Statement 超 时 的 就 不 起 作用 
了 ， 整 体会 使 用 事务 超时 禾 盖 Statement 超 时 。 


6.6 ”NoSQL 客 户 端 超时 


对 于 MongoDB， 我 们 使 用 的 是 spring-datarmongodb 客 户 端 ， 可 以 通过 如 
下 配置 设置 相关 的 超时 时 间 。 


<mongo:mongo id-"tryMongo" replica-set="${try.mongo.hostAndPorts}"> 
<mongo:options 


connections-per-host="${mongo.connectionsPerHost}" 
threads-allowed-to-block-for-connection-multiplier- 
"$(mongo.threadsAllowedToBlockForConnectionMultiplier]" 
max-wait-time="${mongo.maxWaitTime}" 
connect-timeout="${mongo.connectTimeout}" 
socket-timeout="${mongo.socketTimeout}" 
socket-keep-alive="$ {mongo.socketKeepAlive}" 
auto-connect-retry="${mongo.autoConnectRetry}" /> 
</mongo:mongo> 


经 就 遇 到 过 因为 不 设置 MongoDB 客 户 端 超时 而 导致 服务 响应 慢 的 
Eite 


对 于 Redis， 我 们 使 用 的 是 Jedis 客 户 端 ， 可 以 通过 如 下 配置 分 配 等 待 获 取 
连接 池 连 接 的 超时 时 间 和 网 络 和 连接 / 读 超时 时 间 。 


PoolJedisConnectionFactory cmnectionFactory -new PoolJedisConnectionFactory(); 
connectionFactory.setMaxWaitMillis (maxWaitMillis); 
connectionFactory.setTimeout (timeoutInMillis); 


Jedis 在 建立 Socket 时 通过 如 下 代码 设置 超时 。 


this.socket.connect ( 
new InetSocketAddress(this.host, this.port), this. timeout); 
this.socket.setSoTimeout (this.timeout) ; 


可 以 在 JVM 启 动 时 通过 添加 -Dsun.net.client.defaultConnectTimeout=60000- 
Dsun.net.client.defaultReadTimeout=60000 来 配置 默认 的 全 局 Socket 连 接 / 读 
超时 。 即 如 Httpclient、JDBC 等 ， 如 果 没 有 配置 Socket 超 时 ， 则 会 默认 使 
用 该 超时 。 


67 ”业务 超时 


业务 超时 分 为 如 下 两 类 。 


任务 型 ， 比 如 ， 订 单 超时 未 支付 取消 超时 活动 自动 关闭 等 ， 这 属于 任务 
型 超时 ， 可 以 通过 Worker 定 期 扫描 数据 库 修改 状态 。 有 时 需要 调用 的 远 
程 服务 超时 了 (比如 ， 用 户 注 册 成 功 后 ， 和 需要 给 用 户 发 放 优惠 券 ) ， 可 
以 考虑 使 用 队列 或 者 暂时 记录 到 本 地 稍 后 重 试 。 


- 服务 调用 型 : 比如 ， 某 个 服务 的 全 局 超时 时 间 为 500ms， 但 我 们 有 多 处 
服务 调用 ， 每 处 服务 调用 的 超时 时 间 可 能 不 一 样 ， 此 时 ， 可 以 简单 地 使 
用 Future 来 解决 问题 ， 通 过 如 Future.get(3000, TimeUnit. MILLISECONDS) 
来 设置 超时 。 


6.8 “前端 Ajax 超时 


| 门 使 用 jQuery 来 进行 Ajax 请 求 ， 可 以 在 请 求 时 带 上 timeout 参 数 设 置 超时 
时 间 。 


S.ajax({ 

url: "http://ins.jd.com:9090/test", 

dataType:"jsonp", 

jsonp:"test", 

jsonpCallback:"test", 

timeout:2000, 

success: function(result,status,xhr) { 
//success 


hy 
error: function(result,status,xhr) { 
if(status == 'timeout') { 


//timeout 


)); 


当 进 行 跨 域 JSONP 请 求 并 使 用 jQuery 1.4.x 版 本 时 ，IE9、Chrome 52 ` 
Firefox 49 测 试 JSJONP， 请 求 在 超时 后 不 能 被 取消 ， 即 使 客户 端 超时 了 ， 
该 脚本 也 将 一 直 运 行 ;， 而 使 用 jQuery 1.5.2 时 ， 超 时 是 起 作用 的 ， 但 是 发 
出 去 的 请 求 是 不 会 被 取消 的 (请 求 还 处 于 执行 状态 ) 。 


还 有 一 种 办 法 可 进行 超时 重 试 ， 即 通过 setTimeout 进 行 超时 重 试 。 比 如 ， 
京东 首页 的 某 个 异步 接口 ， 其 中 一 个 域名 (AUS) 超时 了 ， 想 超时 后 通 
过 另 一 个 域名 (BIS) 重新 获取 数据 ， 代 码 如 下 所 示 。 


var id = setTimeout(retryCallback, 5000); 
S.ajax({ 
dataType: 'jsonp', 
success: function() { 
clearTimeout (id); 


)); 
除了 客户 端 设置 超时 外 ， 服 务 器 端 也 一 定 要 配置 合理 的 超时 时 间 。 
6.9 ”总 结 


JUN 


本 章 主要 介绍 了 如 何在 Web 应 用 访问 的 整个 链 路 上 进行 超时 时 间 设 置 。 通 
过 配置 合理 的 超时 时 间 ， 防 止 出 现 某 服务 的 依赖 服务 超时 时 间 太 长 且 咯 
WE, DISCE CU NIIS EE Se Bayt 。 


FP X MARS as ine VIA ea P] TB], Tf A X f fee n] DAR 
比 服务 器 端 更 长 的 超时 时 间 。 如 有 果 存 在 多 级 依赖 关系 ， 如 A 调用 B，B 调 
用 C， 则 超时 设置 应 该 是 A>B>C， 否 则 可 能 会 一 直 重 试 ，3 引 起 DDoS 攻 击 
效果 。 不 过 最 终 如 何 选择 还 是 要 看 场景 ， 有 时 候 客户 端 设置 的 超时 时 间 
pur aN dee ce M 
DDoS ° 


超时 之 后 应 该 有 相应 的 策略 来 处 理 ， 常 见 的 策略 有 重 试 (等 一 会 儿 再 
试 、 壬 试 其 他 分 组 服务 、 尝 试 其 他 机 房 服 务 ， 重 试 算法 可 考虑 使 用 如 指 
数 退 避 算 法 ) 、 摘 掉 不 存活 万 点 (负载 均衡 /分 布 式 缓存 场景 下 ) > HER 
(返回 历史 数据 /静态 数据 /缓存 数据 ) 、 等待 页 或 者 错误 页 。 


对 于 非 壳 等 写 服 务 应 避免 重 试 ， 或 者 可 以 考虑 提前 生成 唯一 流水 号 来 保 
证 写 服 务 操作 通过 判断 流水 号 来 实现 项 等 操作 。 


在 进行 数据 库 / 缓 存 服务 器 操作 时 ， 记 得 经 常 检查 慢 查 询 ， 慢 得 询 通 常 是 
引起 服务 出 问题 的 罪魁 镶 首 。 也 要 考虑 在 超时 严重 时 ， 直 接 将 该 服务 降 
级 ， 行 该 服务 修复 后 再 取消 降级 。 


对 于 有 负载 均衡 的 中 间 件 ， 请 竹 谍 配置 心跳 / 存 污 和 检查 ， 而 不 征 傅 性 检 


超时 重 试 必 然 导致 请 求 响应 时 间 增加 ， 最 坏 情 况 下 的 响应 时 间 = 重 试 次 数 
x 单 次 超时 时 间 ， 这 很 可 能 严重 影响 用 户 体验 ， 导 致 用 户 不 断 刷新 页 面 来 
重复 请 求 ， 最 后 导致 服务 接收 的 请 求 太 多 而 挂 掉 ， 因 此 除了 控制 单 次 超 
时 时 间 ， 也 要 控制 好 用 户 能 忍受 的 最 长 超时 时 间 。 


超时 时 间 太 短 会 导致 服务 调用 成 功率 降低 ， 超 时 时 间 太 长 又 会 导致 本 应 
成 功 的 调用 却 失 败 了 ， 这 也 要 根据 实际 场景 来 选择 最 适合 当前 业务 的 超 
时 时 间 ， 甚 至 是 程序 动态 上 自动 计 算 超 时 时 间 。 比 如 商品 详情 页 的 库存 状 
态 服务 ， 可 以 设置 较 短 的 超时 时 间 ， 当 超时 时 降级 返回 有 货 ， 而 结算 页 
服务 就 需要 设置 稍微 长 一 些 的 超时 时 间 保 证 确实 有 货 。 


在 实际 开发 中 ， 不 要 轻视 超时 时 间 ， 很 多 重大 事故 都 是 因为 超时 时 间 不 
poH ea aa 
泵 的 代码 吧 。 
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[9]  http://stackoverflow.com/questions/1002367/jquery-ajax-jsonp-ignores-a- 
timeoutand-doesnt-fire-the-error-event 


7 BAHL 


回 深 是 指 当 程序 或 数据 出 错时 ， 将 程序 或 数据 恢复 到 最 近 的 一 个 正确 版 

本 的 行为 。 最 常见 的 如 事务 回 深 、 代 码 库 回 深 、 部 署 版 本 回 深 、 数 据 版 

AL 静态 资源 版 本 回 深 等 。 通 过 回 深 机 制 可 保证 系统 在 某 些 场景 下 
s IR] H o 
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在 执行 数据 库 SQL 时 ， 如 果 我 们 检测 到 事务 提交 冲突 ， 那 么 事务 中 所 有 
已 执行 的 SQL 要 进行 回 深 ， 目 的 是 防止 数据 库 出 现 数据 不 一 致 。 对 于 单 
库 事务 回 深 直接 使 用 相关 SQL 即 可 。 如 有 果 涉 及 分 布 式 数据 库 ， 则 要 考虑 
使 用 分 布 式 事务 ， 最 常见 的 如 两 阶段 提交 、 三 阶段 提交 协议 ， 这 种 方式 
实现 事务 回 滚 难 度 较 低 ， 但 是 对 性 能 影响 比较 大 ， 因 为 我 们 在 大 多 数 场 
景 中 需要 的 是 最 终 一 致 性 ， 而 不 是 强 一 致 性 。 因 此 ， 可 以 考虑 如 事务 


表 、 消 息 队 列 、 补 偿 机 制 OUTER) 、TCC 模 式 〈 预 占 /确认 /取消 ) ^ 
Sagas 模 式 〈 拆 分 事务 + 补偿 机 制 ) 等 实现 最 终 一 致 性 。 比 如 ， 电 商 中 的 
单 场景 ， 会 进行 扣 减 优惠 券 、 预 占 库 存 等 操作 ， 这 涉及 非常 多 的 子 系 
统 ， 因 此 ， 很 难 使 用 分 布 式 事务 保证 强 一 致 性 ， 我 们 只 要 能 保证 最 终 一 
致 性 即 可 ， 下 面 来 看 看 结算 下 单 序列 图 。 


结算 服务 | 优惠 券 服务 | 库存 服务 


订单 服务 | 


扣 减 优惠 券 、! 


ma T 扣 减 库存 | 


Si OHNE | 保存 订单 


l 
l 
E ERE ， 


一 种 情况 是 当 订 单 出错 后 ， 要 把 之 前 扣 减 的 优惠 券 和 库存 回 深 。 但 是 ， 
当 保存 订单 出 错时 ，JVM 实 例 挂 挥 了 ， 那 么 之 前 扣 减 的 优惠 券 和 库存 就 
没有 回 演 ， 这 种 情况 可 以 考虑 在 本 地 记录 事务 日 志 ， 当 JVM 实 例 重 启 
后 ,分析 事务 日 志 重 新 问 深 ， 当 然 也 可 以 记录 事务 日 志 表 ， 或 者 通过 补 
偿 机 制 ， 定 期 扫描 优惠 券 和 库存 使 用 表 ， 回 深 没 有 关联 订单 的 或 者 已 取 
消 订单 的 记录 。 还 有 一 种 情况 是 下 单 后 一 直 没 有 文 付 ， 比 如 6 小 时 ， 没 有 
文 付 的 订单 要 取消 ， 此 时 束 要 定期 扫 揪 订单 表 ， 然 后 取消 订单 并 回 深 优 
患 券 和 库存 。 不 管用 什么 方式 ， 只 要 保证 最 终 一 致 性 即 可 。 


7.2 ”代码 库 回 滚 


在 开发 项 目 时 ， 一 定 要 将 代码 维护 到 代码 仓库 ， 从 而 进行 版 本 管理 。 常 
见 的 有 SVN、Git 等 ，SVN 是 一 于 集中 版 本 控制 系统 ， 而 Git 是 一 款 分 布 式 
版 本 控制 系统 。 有 了 版 本 控制 系统 后 就 可 以 记录 代码 的 历史 版 本 ， 在 出 
问题 后 可 以 方便 回 深 。 当 某 个 代码 文件 部 署 出 现 问题 时 ， 可 以 通过 历史 
版 本 查看 是 谁 修改 的 、 修 改 了 什么 ， 从 而 快速 定位 出 BUG。 另 外 ， 在 实 
际 开 发 过 程 中 ， 可 能 存在 多 个 版 本 并 行 开发 ， 此 时 版 本 控制 系统 的 分 文 


功能 吏 发 挥 大 作用 了 ， 大 家 在 各 目 分 文 上 开发 测试 ， 相 互 不 影响 ， 开 发 
完成 后 合并 分 文 到 主干 即 可 。 


7.3 ”部 署 版 本 回 滚 


代码 测试 完成 后 ， 接 下 来 就 要 进行 系统 的 部 署 ， 在 部 署 系 统 时 ， 要 考虑 
当代 码 逻 辑 出 现 错误 后 如 何 快速 恢复 ， 总 结 为 部 署 版 本 化 、 小 版 本 增 量 
发 布 、 大 版 本 砍 度 发 布 、 染 构 升 级 并 发 发 布 。 


1. 部 署 版 本 化 


每 次 部 署 时 ， 应 该 将 上 一 版 本 的 包 记 录 到 部 署 系统 中 ， 在 发 布 时 应 该 采 
用 全 量 发 布 ， 避 人 免 增 量 发 布 (只 发 布 修改 过 的 类 或 文件 ，。 如 有 需要 ， 
全 量 版 本 可 直接 回 深 ， 不 会 受到 约束 或 限制 。 


2. 小 版 本 增 量 发 布 


比如 修复 BUG， 添 加 一 些 人 简单 的 业务 逻辑 ， 这 些 我 们 叫 作 小 版 本 。 增 量 
发 布 的 意思 是 比如 我 们 有 100 台 服务 器 ， 先 发 布 1 台 验证 ， 如 采 没 问题 ， 
则 接着 发 布 10 台 ， 最 后 全 量 发 布 。 


3. 大 版 本 灰 度 发 布 


在 页 面 改版 、 添 加 新 的 功能 时 需要 进行 灰 度 发 布 ， 一 般 情况 下 是 两 个 版 
本 并 行 跑 一 段 时 间 ， 一 些 用 户 访问 老 版 本 ， 一 些 用 户 访问 新 版 本 ， 功 能 
验证 成 功 后 或 者 新 版 本 效果 不 错时 ， 再 全 量 发 布 。 比 如 ， 我 们 可 以 通过 
类 似 如 下 带 有 版 本 号 的 URL 来 区 分 新 版 本 和 老 版 本 。 


https://cd.jd.com/yanbao/v3? 


skuld=854073&cat=652,654,832&brandId=8983& 
area-1 2810 51081 O&callback-yanbao jsonp callback 
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党 快速 地 切换 回 老 版 本 。 


4. 架 构 升级 并 发 发 布 
以 构 升级 后 ， 我 们 不 大 清楚 痢 版 本 是 否 功能 正 前 ， 因 此 ， 新 老 版 本 部 署 


集群 会 同时 存在 一 段 时 间 。 然 后 ， 等 所 有 流量 迁移 到 新 版 本 集群 后 ， 老 
版 本 集群 就 可 以 下 线 了 。 


一 般 前 端 应 用 我 们 会 采用 Nginx 作 为 接 入 层 ， 通 过 A/B 方 式 慢 慢 地 将 流量 
引入 到 新 版 本 集群 ， 比 如 1% 一 10% 一 50% 一 100%。 如 果 新 版 本 集群 处 理 
出 现 问题 ， 那 么 要 上 自动 降级 到 老 版 本 集群 继续 服务 。 若 新 版 本 出 现 大 面 
积 故障 ， 则 要 将 所 有 流量 引入 到 老 版 本 集群 。 因 此 ， 接 入 层 要 能 灵活 挖 
制 流量 方向 。 示 意图 如 下 图 所 示 。 


新 版 本 出 错 后 自 
动 降级 为 老 版 本 


A/B 测 试 


新 版 本 集群 


失败 降级 我 们 可 以 借助 Nginx 的 error page ° 


proxy intercept errors on; 
recursive error pages on; 


location ~* "^/(Xd*)X.html$" { 

proxy pass http://new version/$1.html; 

error page 500 502 503 504 -200 /fallback version/$1.html; 
} 


失败 降级 是 很 重要 的 特性 ， 关 键 时 候 不 至 于 让 用 户 不 能 访问 或 者 看 到 日 
屏 ， 如 果 有 CDN， 则 切换 版 本 时 一 定 要 记得 去 掉 CDN 。 


7.4 数据 版 本 回 滚 


有 些 特 定 行业 业务 数据 中 的 商品 /价格 数据 需要 进行 版 本 化 处 理 ， 一 方面 
为 了 审计 需要 ， 另 一 方面 为 了 出 现 问 题 时 能 及 时 回 滚 。 版 本 化 设计 可 以 
基于 下 图 的 架构 。 


+++ 
发 布 


设计 版 本 化 数据 结构 时 ， 有 两 种 思路 : 全 量 和 增 量 。 全 量 版 本 化 是 指 即 
使 只 变更 了 其 中 一 个 字段 也 将 整体 记录 进行 历史 版 本 化 ， 保 存 的 数据 量 
比较 多 ， 但 是 回 滚 方便 。 而 增 量 版 本 化 是 指 只 保存 变化 的 字段 ， 保 存 的 
数据 量 较 少 ， 但 是 回 滚 起 来 很 及 烦 ， 需 要 回溯 。 因 此 ， 为 了 简单 化 处 理 
一 般 采 用 全 量 版 本 化 机 制 。 


态 外 ， 在 设计 消息 队列 时 ， 重 要 业务 会 对 消息 进行 副本 处 理 ， 以 便 万 一 
业务 逻辑 出 现 问 题 能 进行 历史 数据 回 演 ， 从 而 修复 问题 。 


7.5 “静态 资源 版 本 回 滚 


在 前 端 开 发 中 ， 静 态 资源 版 本 也 是 会 经 常 变更 的 ， 如 JS/CSS， 而 每 次 内 
容 变 更 时 我 们 都 会 生成 一 个 全 量 新 版 本 放 到 项 目的 deploy 目 录 中 ， 从 而 保 
证 版 本 可 追 滴 ， 出 现 问 题 时 能 及 时 回 滚 。 目 录 结 构 如 下 图 所 示 。 


© deploy 
[3 assets 
N default 
四 main 
B 10.13 
四 1.0.14 
B 10.15 
O css 
Djs 
O widget 


因为 静态 资源 一 般 放 在 CDN 上 ， 所 以 缓存 时 间 设 置 得 比较 长 ， 比 如 1 个 
月 。 这 样 知 发 布 的 版 本 有 问题 ， 则 需要 清理 CDN 缓 在 ， 也 需要 清理 浏 蜗 
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操作 正确 。 


` 发 布 新 的 静态 资源 到 源 服务 器 。 
` 清理 CDN 绥 存 ， 从 而 可 以 回 源 服务 器 获取 最 新 的 静态 资源 。 
在 新 的 URL 上 添加 随机 数 并 清理 浏览 硕 缓 在， 代码 如 下 。 


«script type="text/javascript" ^ src-"/js/index.js?time-201610231111"»«/ 
script> ° 


而 全 量 版 本 机 制 是 最 可 靠 的 方式 ， 我 们 先 部 署 全 量 版 本 ， 然 后 通过 如 下 
ASH s 


<script type-"text/javascript" src-"/1.0.16/js/index.js"»«/script^ 


在 当前 发 布 版 本 出 现 问题 时 ， 只 需要 将 版 本 号 更 改 为 上 一 个 版 本 号 即 
可 ， 不 需要 清理 CDN、 不 需要 清理 浏览 锅 缓 存 。 


当然 ， 这 里 要 设置 合理 的 服务 器 端 页 面 缓存 时 间 ， 比 如 2 分 钟 ， 用 户 看 到 
彰 误 的 发 布 版 本 最 多 2 分 钟 时 间 。 为 了 方便 测试 ， 可 以 在 请 求 参 数 中 加 入 
版 本 号 ， 如 http://item.jd.com/2381431.html?version=1.0.15， 方 便 验 证 老 版 
本 或 者 测试 新 版 本 ， 使 得 测试 或 验证 多 个 版 本 时 ， 不 需要 来 回 修改 服务 
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8 压 测 与 预案 


在 大 促 来 临 之 前 ， 人 研发 人 员 需 要 对 现 有 系统 进行 梳理 ， 发 现 系统 瓶颈 和 
问题 ， 然 后 进行 系统 调 优 来 提升 系统 的 健壮 性 和 处 理 能 力 。 一 般 通 过 系 
统 压 测 来 发 现 系统 瓶 贷 和 问题 ， 然 后 进行 系统 优化 和 容 灾 (如 系统 参数 
调 优 、 单 机 房 容 灾 、 多 机 房 容 灾 等 ) 。 即 使 已 经 把 系统 优化 和 容 灾 做 得 
非常 好 了 ， 但 也 存在 一 些 不 稳定 因素 ， 如 网 络 、 依 赖 服务 的 SLA 不 稳定 
等 ， 这 就 需要 我 们 制定 应 急 预 案 ， 在 出 现 这 些 因 素 后 进行 路 由 切换 或 降 
级 处 理 。 在 大 促 之 前 需要 进行 预案 演习 ， 确 保 预 案 的 有 效 性 。 


8.1 系统 压 测 


压 测 一 般 指 性 能 压力 测试 ， 用 来 评估 系统 的 稳定 性 和 性 能 ， 通 过 压 测 数 
据 进 行 系统 容量 评 佑 ， 从 而 决定 是 否 需 要 进行 扩容 或 缩 容 。 


压 测 之 前 要 有 压 测 方案 【如 压 测 接口 、 并 发 量 、 庄 测 策略 (RE ` 
加 压 、 并 发 量 ) 、 压 测 指标 〈 机 器 负载 、QPSATPS、 响 应 时 间 ) ) ， 
要 产 出 压 测报 告 【 讨 测 方案 、 机 器 负载 、QPSATPS、 啊 应 时 间 (平均 、 
小 、 最 大 ) 、 成 功率 、 相 关 参 数 (JVM 参 数 、 压 缩 参 数 ) 等 ] ， 最 后 根 
据 压 测报 告 分 析 的 结 采 进行 系统 优化 和 容 灾 。 


8.1.1 线 下 压 测 


通过 如 JMeter、Apache ab 压 测 系 统 的 某 个 接口 (如 查询 库存 接口 ) 或 者 
某 个 组 件 (如 数据 库 连 接 池 ) ， 然 后 进行 调 优 (如 调整 JVM 参 数 、 优 化 
ES) ， 实 现 单个 接口 或 组 件 的 性 能 最 优 。 


线 下 压 测 的 环境 〈 比 如 ， 服 务 右 、 网 络 、 数 据 量 等 ) 和 线 上 的 完全 不 一 
很 难 进行 全 链 路 压 测 ， 适 合 组 件 级 的 压 测 ， 数 据 只 能 


8.1.2 EEM 


线 上 压 测 的 方式 非 第 多 ， 按 读 写 分 为 读 压 测 、 写 压 测 和 混合 压 测 ， 按 数 
据 仿真 度 分 为 仿真 压 测 和 引流 压 测 ， 按 是 否 给 用 户 提 供 服务 分 为 隔离 集 
群 压 测 和 线 上 集群 压 测 。 


读 压 测 是 压 测 系统 的 读 流量 ， 比 如 ， 压 测 商 品 价格 服务 。 写 压 测 是 压 测 
系统 的 写 流量 ， 比 如 下 单 。 写 压 测 时 ， 要 注意 把 压 测 写 的 数据 和 真实 数 
据 分 离 ， 在 压 测 完成 后 ， 删 除 压 测 数据 。 只 进行 读 或 写 压 测 有 时 是 不 能 
发 现 系 统 瓶颈 的 ， 因 为 有 时 读 和 写 是 会 相互 影响 的 ， 因 此 ， 这 种 情况 下 
要 进行 混合 压 测 。 


仿真 压 测 是 通过 模拟 请 求 进行 系统 压 测 ， 模 拟 请 求 的 数据 可 以 是 使 用 程 
序 构造 、 人 工 构造 〈 如 提前 准备 一 些 用 户 和 商品 ) ， 或 者 使 用 Nginx 访 问 
日 志 ， 如 采 压 测 的 数据 量 有 限 ， 则 会 形成 请 求 热点 。 而 更 好 的 方式 可 以 
著 虚 引流 压 测 ， 比 如 使 用 TCPCopy 复 制 线 上 真实 流量 ， 然 后 引流 到 压 测 
集群 进行 压 测 ， 还 可 以 将 流量 放大 N 倍 ， 来 观察 服务 器 负载 能 力 。 


隔离 集群 压 测 是 指 将 对 外 提供 服务 的 部 分 服务 右 从 线 上 集群 摘除 ， 然 后 
将 线 上 流量 引流 到 该 集群 进行 讨 测 ， 这 种 方式 很 安全 。 有 时 也 可 以 直接 


对 线 上 集群 进行 压 测 ， 如 通过 缩减 线 上 服务 器 数量 实现 ， 通 过 增 大 单 
服务 右 的 负载 进行 压 测 ， 这 种 方式 风险 很 大 ， 通 过 逐步 减少 服务 
47, 并且 在 后 半夜 用 户 少 的 时 候 进 行 。 


单机 压 测 钙 指 对 集群 中 的 一 台 机 絮 进 行 压 测 ， 从 而 评估 出 单机 极限 处 理 
能 力 ， 发 现 单机 的 瓶颈 点 ， 这 样 可 以 把 单机 性 能 优化 到 极致 。 但 实际 集 
群 的 瓶颈 往往 是 其 依赖 的 系统 或 服务 ， 如 数据 库 、 缓 存 或 者 调用 的 服 
务 ， 因 此 单机 压 测 的 结果 不 能 反映 集群 整体 处 理 能 力 ， 也 需要 进行 集群 
压 测 ， 从 而 评 信 出 集群 的 极限 处 理 能 力 ， 从 而 有 和 针对 性 地 对 集群 依赖 的 
系统 或 服务 进行 优化 。 


在 压 测 时 ， 也 应 该 选择 离散 压 测 ， 即 选择 的 数据 应 该 是 分 散 的 或 者 长 尾 
的 ， 比 如 ， 刚 刚 新 增 的 商品 一 般 在 缓存 中 ， 而 去 年 已 经 下 架 的 商品 已 经 
从 缓存 中 移 除 ， 刚 刚 新 增 的 商品 往往 是 热点 数据 ， 而 去 年 已 下 架 的 商品 
0 
理 能 力 。 


另外 ， 在 实际 压 测 时 应 该 进行 全 链 路 压 测 ， 因 为 可 能 存在 一 个 非 核心 系 
统 服务 调用 问题 造成 整个 交易 链 路 出 现 问题 ， 或 者 链 路 中 的 各 个 系统 存 
在 竞争 资源 的 情况 ， 因 此 为 了 保证 压 测 的 真实 性 ， 应 该 进行 全 链 路 压 
测 ， 通 过 全 链 路 压 测 来 发 现 问 题 。 


8.2 ”系统 优化 和 容 灾 


拿 到 压 测报 告 后 ， 接 下 来 会 分 析 报告 ， 然 后 进行 一 些 有 针对 性 的 优化 ， 
如 硬件 升级 、 系 统 扩容 、 参 数 调 优 、 代 码 优化 (如 代码 同步 改 异步 ) > 
架构 优化 如 加 缓存 、 读 写 分 离 、 历 史 数据 归档 ) 等 。 不 要 把 别人 的 经 
给 或 襟 例 全 来 直接 大 在 日 己 的 场景 下， 一 定 要 压 测 ， 相 信 压 测 数 据 而 丰 
是 别人 的 案例 。 


在 进行 系统 优化 时 ， 要 进行 代码 走 查 ， 发 现 不 合理 的 参数 配置 ， 如 超时 
时 间 、 降 级 策略 、 绥 存 时 间 等 。 在 系统 压 测 中 进行 慢 查 询 排查 ， 包 括 
Redis、MySQL 等 ， 通 过 优化 查询 解决 慢 查 询问 题 。 系 统 优 化 和 高 并 发 系 
统 的 稳定 性 保障 可 扫 二 维 码 参考 肖 飞 的 《高 性 能 高 并 发 系统 的 稳定 性 保 
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障 》 


在 应 用 系统 扩容 方面 ， 可 以 根据 去 年 流量 、 与 运营 业务 方 沟通 促销 力 
度 、 最 近 一 段 时 间 的 流量 来 评估 出 是 否 需要 进行 扩容 ， 需 要 扩容 多 少 
倍 ， 比 如 ， 预 计 GMV 增 长 100%， 那 么 可 以 考虑 扩容 2~3 倍 容量 。 还 要 根 
据 系 统 特点 进行 评估 ， 如 商品 详情 页 可 能 要 文 持 平常 的 十 几 倍 流量 ， 如 
秒杀 系统 可 能 要 文 持 平常 的 几 十 倍 流量 。 扩 容 之 后 还 要 预 留 一 些 机 器 应 
对 突 发 情况 ， 在 扩容 上 尽量 支持 快速 扩容 ， 从 而 出 现 突 发 情况 时 可 以 几 
分 钟 内 完成 扩容 。 


不 要 把 所 有 鸡蛋 放 进 一 个 篮子 ， 在 扩容 时 要 考虑 系统 容 灾 ， 比 如 分 组 部 
署 、 跨 机 房 部 署 。 容 灾 是 通过 部 署 多 组 〈 单 机 房 / 多 机 房 ) 相同 应 用 系 
统 ， 当 其 中 一 组 出 现 问题 时 ， 可 以 切换 到 另 一 个 分 组 ， 保 证 系统 可 用 。 


8.3 ”应 急 预 案 


在 系统 压 测 之 后 会 发 现 一 些 系 统 瓶 贷 ， 在 系统 优化 之 后 会 提升 系统 否 吐 
量 并 降低 啊 应 时 间 ， 容 灾 之 后 的 系统 可 用 性 得 以 保障 ， 但 还 是 会 存在 一 
些 风险 ， 如 网 络 抖动 、 某 台 机 融 负 载 过 高 、 某 个 服务 变 慢 、 数 据 库 Load 
值 过 高 等 ,为 了 防止 因为 这 些 问题 而 出 现 系统 雪 朋 ， 需 要 针对 这 些 情 况 
制定 应 急 预 案 ， 从 而 在 出 现 突 发 情况 时 ， 有 相应 的 措施 来 解决 掉 这 些 问 


题 


应 急 预 案 可 按照 如 下 几 步 进行 : 首先 进行 系统 分 级 ， 然 后 进行 全 链 路 分 
析 、 配 置 监控 报警 ， 最 后 制定 应 急 预 案 。 


系统 分 级 可 以 按照 交易 核心 系统 和 交易 文 撑 系统 进行 划分 。 交 易 核心 系 
统 ， 如 购物 车 ， 如 果 挂 了 ， 将 影响 用 户 无 法 购物 ， 因 此 需要 投入 更 多 资 
源 保障 系统 质量 ， 将 系统 优化 到 极致 ， 降 低 事 故 率 。 而 交易 文 撑 系 统 是 
外 围 系统 ， 如 商品 后 人 台 ， 即 使 挂 了 也 不 影响 前 合用 户 购 物 ， 这 些 系统 允 
许 暂 时 不 可 用 。 实 际 系统 分 级 要 根据 公司 特色 进行 ， 目 的 古 对 不 同 级 别 


的 系统 实施 不 同 的 质量 保障 ， 核 心 系统 要 投入 更 多 资源 保障 系统 高 可 
H, 外围 系 统 要 投入 较 少 资源 允许 系统 暂时 不 可 用 。 


系统 分 级 后 ， 接 下 来 要 对 交易 核心 系统 进行 全 链 路 分 析 ， 从 用 户 入 口 到 
后 端 存储 ， 梳 理 出 各 个 关键 路 径 ， 对 相关 路 径 进行 评估 并 制定 预案 。 即 
当 出 现 问题 时 ， 该 路 径 可 以 执行 什么 操作 来 保证 用 户 可 下 单 、 可 购物 ， 
并 且 也 要 防止 问题 的 级 联 效应 和 雪 裔 效应 。 


如 下 图 所 示 ， 梳 理 系统 全 链 路 关键 路 径 ， 包 括 网 络 接 入 层 、 应 用 接 入 
人 


络 接 入 层 
网 络 接 入 层 T 


智能 DNS 


VIP: 1.1.1.1 机 房 A| 机 房 B VIP: 2.111 


dim D Merc 


R 


erro [serm | | aro [serm — ] 


(3 IP: 192.168.1.x (3) IP: 192.168.1.x 
ET 服务 Nginx(OpenResty) 统一 服务 Nginx(OpenResty) 


R 


四 >——" 
统一 服务 Web 服 务 (Tomcat) 统一 服务 Web 服 务 (Tomcat) 


5.1 


4 


(6) 


网 络 接 入 层 : ”由 系统 工程 师 负 责 ， 主 要 关注 是 机 房 不 可 用 、DNS 故 障 、 
VIP 故障 等 预案 处 理 。 


序 号 | 预案 名 称 | 问题 描述 | 执行 操作 相关 干系 人 


从 DNS 摘除 该 机 房 入 口 ， 或 者 
1 沁 房 故障 La A 公 网 入 口 DNS: 小 A 
ea mm DNS 到 其 他 机 房 
现 网 络 拌 | 世 
VIP 网 络 异 党 如 某 VIP 出 现 网 络 拌 | 切换 到 备用 VIP — € 
动 ， 暂 时 无 法 解决 


应 用 接 入 层 : 由 开发 工程 师 负 责 ， 主 要 关注 点 是 上 游 应 用 路 由 切换 、 限 
流 、 降 级 、 隔 离 等 预案 处 理 。 


序 s 问题 描述 执行 操作 相关 干系 人 
某 些 IP 访问 量 太 大 导致 上 
ilf Web 应 用 负载 压力 过 高 


3 IP 限 流 实施 IP 限 流 小 C 


如 硬件 故障 、 负 载 高 、GC | 摘除 异常 节点 , 或 者 如 果 某 个 机 
3 上 游 应 用 异常 l 小 C 
慢 、 响 应 慢 房 有 问题 ， 切 换 路 由 到 其 他 机 房 


超时 自动 降级 为 仅 查 缓存 或 库 


上 游 库 存 服 务 | 如 超时 、 后 端 服务 异常 、 网 


3 eed 存 有 货 ,服务 异 常 时 手工 全 部 降 | C 
EUN 级 为 库存 有 货 
假 虫 降级 为 返回 静态 化 资源 , 或 
疏 虫 量 占 实际 访问 量 的 | 人 
3 enga 者 息 虫 隔离 到 单独 上 游 集群 提 | 小 C 


1/10 
供 服务 


3 机 房 切换 机 房 AJVM 升级 流量 路 由 切换 到 机 房 B 小 C 


Web 应 用 层 和 服务 层 : 由 开发 工程 师 负责 ，Web 应 用 层 和 服务 层 应 用 策 
略 差不多 ， 主 要 关注 点 是 依赖 服务 的 路 由 切换 、 连 接 池 (数据 库 、 线 程 
池 等 ) 异常 、 限 流 、 超 时 降级 、 服 务 异常 降级 、 应 用 负载 异常 、 数 据 库 
故障 切换 、 缓 存 故障 切换 等 。 


序号 | 预案 名 称 | ”问题 描述 | 执行 操作 相关 干系 人 


茶 商 品 服务 访问 超时 ,响应 | 切换 商品 服务 到 本 机 房 其 他 分 


4 “| 商品 服务 异常 ND 
NAT | 组 ， 或 者 其 他 机 房 分 组 

线程 池 设置 得 太 小 , 导致 请 

4 “| 线程 池 不 够 用 | “| 提供 开关 ,动态 调整 线程 池 大 小 | ”小 D 
求 有 积压 

请 求 量 太 大 ,超过 实际 的 处 | 客户 端 限 流 ， 设 置 请 求 阔 值 ， 当 

4 “| 请 求 量 太 大 | banaai 小 D 

理 能 超出 阔 值 后 ,请 求 自动 降级 处 理 
应 用 : 小 D 


和 品 服务 压力 | 由 于 异常 ,导致 查询 商品 服 
4 客户 端 暂 停 查询 ， 或 限 流 商品 服务 : 
过 - 务 的 调用 量 太 大 , 打 不 住 | TATE " 


小 E 
自动 切换 到 其 他 分 组 , 或 者 切换 
4 导致 服务 调用 大 面积 超时 | 、 小 D 
到 其 他 机 房 
服务 器 端 限 流 ， 设置 服务 器 端 总 
5 mie: ESAE KERSE] p 
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数据 层 由 开发 工程 师 或 系统 工程 师 负 责 ， 主 要 关注 点 是 数据 库 /缓存 负 
载 高 、 数 据 库 / 缓 存 故障 等 。 


预案 名 称 问题 描述 执行 操作 相关 干系 人 


MySQL 硬件 故 — À 联系 DBA 进行 MySQL 主 从 切换 , | 应 用 : 小 D 
障 E 切换 完成 后 验证 应 用 MySQL: /^F 


X Redis 挂 掉 ， 无 法 应 用 : 小 D 
Redis 挂 掉 dd 联系 Redis 服务 人 进行 主 从 切换 
edis: 小 


5f 


LH 
某 机 房 断 电 或 者 发 
生 灾 难 


切换 所 有 数据 库 /缓存 到 其 他 机 房 


制定 好 预案 后 ， 应 对 预案 进行 演习 ， 来 验证 预案 的 正确 性 ， 在 制定 预案 
时 也 要 设 定 故 障 的 恢复 时 间 。 有 一 些 故 障 如 数据 库 挂 掉 是 不 可 降级 处 理 
的 ， 对 于 这 种 不 可 降级 的 关键 链 路 更 应 进行 充分 演习 。 演 习 一 般 在 零点 
之 后 ， 这 个 时 间 点 后 用 户 量 相 对 来 说 较 少 ， 即 使 出 了 问题 影响 较 小 。 


最 后 ， 要 对 关联 路 径 实施 监控 报警 ， 包 括 服务 器 监控 (CPU 使 用 率 、 磁 
盘 使 用 率 、 网 络 带宽 等 ) 、 系 统 监控 (系统 存活 、URL 状 态 /内 容 监 控 、 
端口 存活 等 )、JVM 监 控 〈 扒 内 存 、GC 次 数 、 线 程 数 等 ) 、 接 口 监控 


[接口 调用 量 (每 秒 /每 分 钟 ) 、 接 口 性 能 (TOP50/TOP99/TOP999) ^ 

接口 可 用 率 等 ] 。 然 后 ， 配 置 报警 策略 ， 如 监控 时 间 段 (如 上 午 10:00 一 
13:00、00:00 一 5:00， 不 同时 间 段 的 报警 阔 值 不 一 样 )、 报 警 病 值 (如 每 5 
分 钟 调用 次 数 少 于 100 次 则 报警 ) 、 通 知 方式 (短信 /邮件 ) 。 在 报警 后 要 
观察 系统 状态 、 监 控 数据 或 者 日 志 来 查看 系统 是 否 真 的 存在 故障 ， 如 果 
确实 是 故障 ， 则 应 及 时 执行 相关 的 预案 处 理 ， 避 免 故 障 扩散 。 


想 要 了 解 更 多 大 促 备 战 思 路 和 方法 ， 可 扫 二 维 码 参考 林 世 洪 写 的 《京东 
大 促 备 战 思路 和 方法 2.0 解 密 》。 


积极 预防 问题 


l 


及 时 发 现 问题 


l 


迅速 决策 /处 理 
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9 应 用 级 缓存 
9.1 缓存 简介 


缓存 ， 笔 者 的 理解 是 让 数据 更 接近 于 使 用 者 ， 目 的 是 让 访问 速度 更 快 。 
工作 机 制定 先 从 缓存 中 读 取 数 据 ， 如 果 没 有 ， 再 从 慢 速 设备 上 读 取 实际 
数据 并 同步 到 缓存 。 那 些 经 常 读 取 的 数据 、 频 繁 访问 的 数据 、 热 点 数 
据 、IO 瓶 绒 数 据 、 计 算 昂 贯 的 数据 、 符 合 5 分 钟 法 则 和 局 部 性 原理 的 数据 
都 可 以 进行 缓存 。 如 CPU 一 LVL2/L3 一 内 存 一 磁盘 就 是 一 个 典型 的 例子 ， 
CPU 和 需要 数据 时 先 从 L1 读 取 ， 如 果 没 有 找到 ， 则 查找 L2/L3 读 取 ， 如 采 没 
有 ， 则 到 内 存 中 查找 ， 如 果 还 没有 ， 会 到 秒 盘 中 查找 。 还 有 比如 用 过 
Maven 的 读者 都 应 该 知道 ， 加 载 依赖 的 时 候 ， 先 从 本 机 仓库 找 ， 再 从 本 地 
服务 器 仓库 找 ， 最 后 到 远程 仓库 服务 器 找 。 男 外 还 有 泉 东 的 物流 为 什么 
0 ee Ee eee 
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本 文 以 Java 应 用 缓存 为 示例 进行 讲解 。 


9.2 ”缓存 命中 率 


缓存 命中 率 是 从 缓存 中 读 取 数据 的 次 数 与 总 读 取 次 数 的 比率 ， 命 中 率直 
高 越 好 。 缓 存 命中 率 = 从 缓存 中 读 取 次 数 / 【总 读 取 次 数 (从 缓存 中 读 取 
次 数 + 从 慢 速 设备 上 读 取 次 数 ) ] 。 这 是 一 个 非常 重要 的 监控 指标 ， 如 
果 做 缓存 ， 则 应 通过 监控 这 个 指标 来 看 缓存 是 否 工作 良好 。 


9.3 ”缓存 回收 策略 
1 基于 空间 


基于 空间 指 缓存 设置 了 存储 空间 ， 如 设置 为 IIMB， 当 达到 存储 空间 上 限 
时 ， 按 照 一 定 的 策略 移 除 数据 。 


2. 基 于 容量 


基于 容量 指 缓存 设置 了 最 大 大 小 ， 当 缓存 的 条 目 超过 最 大 大 小 时 ， 按 照 
一 定 的 策略 移 除 旧 数 据 。 


3. 基 于 时 间 


TTL (Time To Live ) : 存活 期 ， 即 缓存 数据 从 创建 开始 直到 到 期 的 一 
个 时 间 段 〈 不 管 在 这 个 时 间 段 内 有 没有 被 访问 ， 缓 存 数 据 都 将 过 期 ) 。 


Hm (Time To Idle) : 空间 期 ， 即 缓存 数据 多 久 没 被 访问 后 移 除 缓存 的 
Ey [B] e 


4.3 T JavaX 255 | Hi 
软 引 用 : 如 果 一 个 对 象 是 软 引 用 ， 那 么 当 JVM 堆 内 存 不 足 时 ， 垃 圾 回收 
器 可 以 回收 这 些 对 象 。 软 引用 适合 用 来 做 缓存 ， 从 而 当 JVM 推 内存 不 足 


时 ， 可 以 回收 这 些 对 象 腾 出 一 些 空 间 供 强 引 用 对 象 使 用 ， 从 而 避免 
OOM ° 


弱 引 用 : 当 垃 圾 回收 器 回收 内 存 时 ， 如 果 发 现 弱 引用 ， 则 将 它 立 即 回 
收 。 相 对 于 软 引 用 ， 弱 引用 有 更 短 的 生命 周期 。 


注意 : 只 有 在 没有 其 他 强 引 用 对 象 引用 弱 引 用 / 软 引 用 对 象 时 ， 垃 圾 回收 
时 才 回 收 该 引用 。 即 如 果 有 一 个 对 象 (不 是 弱 引 用 / 软 引 用 对 象 ) 引用 了 
弱 引 用 / 软 引用 对 象 ， 那 么 垃圾 回收 时 不 会 回收 该 弱 引 用 / 软 引用 对 象 。 
5. 回 收 算法 


和 基于 容量 的 缓存 会 使 用 一 定 的 策略 移 除 旧 数据 ， 常 见 的 
0 o 


FIFO (First In First Out) : 先进 先 出 算法 ， 即 先 放 入 缓存 的 先 被 移 
ER o 


LRU (Least Recently Used) : 最 近 最 少 使 用 算法 ， 使 用 时 间距 离 现在 
最 久 的 那个 被 移 除 。 


LFU (Least Frequently Used) : 最 不 常用 算法 ， 一 定时 间 段 内 使 用 次 
数 (频率 ) 最 少 的 那个 被 移 除 。 


实际 应 用 中 基于 LRU 的 缓存 大 多 ， 如 Guava Cache、Ehcache 支 持 LRU 。 


9.4 Java 缓存 类 型 


BER FE: 使 用 Java 堆 内 存 来 存储 缓存 对 象 。 使 用 堆 缓存 的 好 处 是 没有 序 
列 化 / 反 序 列 化 ， 是 最 快 的 缓存 。 缺 点 也 很 明显 ， 当 缓存 的 数据 量 很 大 
IN, GC (垃圾 回收 ) 暂停 时 间 会 变 长 ， 存 储 容量 受 限于 堆 空 间 大 小 。 一 
般 通 过 软 引 用 / 弱 引 用 来 存储 缓存 对 象 ， 即 当 堆 内 存 不 足 时 ， 可 以 强制 回 
收 这 部 分 内 存 释 放 扒 内 存 空 间 。 一 般 使 用 堆 缓存 存储 较 热 的 数据 。 可 以 
使 用 Guava Cache ` Ehcache 3.x、MapDB 实 现 。 


堆 外 缓存 : 即 缓存 数据 存储 在 堆 外 内 存 ， 可 以 减少 GC 和 暂停 时 间 ( 堆 对 象 
转移 到 堆 外 ，GC 扫 描 和 移动 的 对 象 变 少 了 ) ， 可 以 文 持 更 大 的 缓存 空间 
(只 受 机 器 内 存 大 小 限制 ， 不 受 堆 空间 的 影响 ) 。 但 是 ， 读 取 数 据 时 需 
要 序列 化 / 反 序列 化 ， 因 此 会 比 堆 缓 存 慢 很 多 。 可 以 使 用 Ehcache 3.x ` 
MapDB 实 现 。 


磁盘 缓存 即 缓存 数据 存储 在 磁盘 上 ， 在 JVM 重 启 时 数据 还 是 存在 的 ， 
而 堆 缓 存 / 堆 外 缓存 数据 会 丢失 ， 需 要 重新 加 载 。 可 以 使 用 Ehcache 3.x ^ 
MapDB 实 现 。 


分 布 式 缓存 上 文 提 到 的 缓存 是 进程 内 缓存 和 磁盘 缓存 ， 在 多 JVM 实 例 
的 情况 下 ， 会 存在 两 个 问题 ，1. 单 机 容量 问题 ，2. 数 据 一 致 性 问题 (多 台 
JVM 实 例 的 缓存 数据 不 一 致 怎么 办 ? ) ， 不 过 ， 这 个 问题 不 用 太 纠 结 ， 
既然 数据 允许 绥 存 ， 则 表示 允许 一 定时 间 内 的 不 一 致 ， 因 此 可 以 设置 组 
存 数据 的 过 期 时 间 来 定期 更 新 数据 ; 3. 缓 存 不 命中 时 ， 需 要 回 源 到 DB/ 服 
务 请 求 多 变 问 题 : 每 个 实例 在 缓存 不 命中 的 情况 下 都 会 回 源 到 DB 加 和 载 数 
据 ， 因 此 ， 多 实例 后 DB 整体 的 访问 量 就 变 多 了 ， 解 决 办 法 是 可 以 使 用 如 
一 致 性 哈 希 分 片 算法 。 因 此 ， 这 些 情 况 可 以 考虑 使 用 分 布 式 缓存 来 解 
决 。 可 以 使 用 ehcache-clustered (配合 Terracotta server) 实现 Java 进 程 间 分 
布 式 缓存 。 当 然 也 可 以 使 用 如 Redis 实 现 分 布 式 绥 存 。 


两 种 模式 如 下 。 


- 单机 时 : 存储 最 热 的 数据 到 堆 缓 存 ， 相 对 热 的 数据 到 堆 外 缓存 ， 不 热 的 
数据 到 磁盘 缓存 。 


` 集群 时 : 存储 最 热 的 数据 到 堆 缓 存 ， 相 对 热 的 数据 到 堆 外 缓存 ， 全 量 数 
据 到 分 布 式 缓存 。 


应 用 应 用 1 应 用 2 


l J 
堆 缓存 堆 缓存 | 堆 缓存 

堆 外 缓存 堆 外 缓存 堆 外 缓存 
磁盘 缓存 分 布 式 缓存 分 布 式 缓存 


NZ 


分 布 式 缓存 


接 下 来 ， 我 们 看 看 如 何在 Java 中 使 用 堆 缓 存 、 堆 外 缓存 、 伺 副 缓 存 、 分 布 
式 缓存 ， 是 不 是 感觉 像 L1、L2、L3 级 缓存 架构 。 


Guava Cache 只 提供 堆 缓 存 ， 小 巧 灵 活 ， 性 能 最 好 ， 如 采 只 使 用 堆 缓存 ， 
那么 使 用 它 就 够 了 。 


Ehcache 3.x 提 供 了 堆 缓 存 、 堆 外 缓存 、 磁 盘 缓 存 、 分 布 式 缓存 。 但 是 ， 
其 代码 注释 比较 少 ，API 还 不 完善 (比如 ，2.x 支 持 LRU 、LFU 、FIFO， 
而 3.x 目 前 还 没有 API 设 置 ) ， 功 能 还 不 完善 〈 比 如， 集群 情况 下 ， 个 人 测 
试 结果 是 暂时 不 可 以 在 生产 环境 使 用 ) ， 如 果 需 要 较 稳 定 的 API 和 功能 ， 
则 请 考虑 使 用 Ehcache 2.x (不 支持 堆 外 缓存 ) 。 


MapDB 和 十 一 款 舱 入 式 Java 数 据 库 引擎 和 集合 框架 。 提 供 了 Maps、Sets、 


Lists、 Queues ` Bitmaps% 文 持 ， 还 文 持 ACID 事务 、 增 量 备份 。 文 持 堆 组 
F EIRT ` RRT ° 


9.4.1 MEE 


1.Gauva Cache 实 现 


Cache<String, String» myCache = 
CacheBuilder.newBuilder() 
.ConcurrencyLevel (4) 
.expireAfterWrite(10, TimeUnit. SECONDS) 
.maximumSize(10000) 
.build(); 


然后 可 以 通过 put、getIfPresent 来 读 写 缓存 。CacheBuilder 有 儿 类 参数 : 组 
存 回收 策略 、 并 发 设置 、 统 计 命中 率 等 。 


缓存 回收 策略 /基于 容量 

maximumSize: 设置 缓存 的 容量 ， 当 超出 maximumSize 有 上 时， 按照 LRU 进 
行 缓存 回收 。 

缓存 回收 策略 /基于 时 间 


expireAfterWrite: 设置 TTL， 绥 存 数据 在 给 定 的 时 间 内 没有 写 (QUEE 
盖 ) 时 ， 则 被 回收 ， 即 定期 会 回收 缓存 数据 。 

expireAfterAccess: 设置 TTI， 缓 存 数据 在 给 定 的 时 间 内 没有 被 读 / 写 时 , 
则 被 回收 。 每 次 访问 时 ， 都 会 更 新 它 的 TTI， 从 而 如 果 该 缓存 是 非常 热 的 
数据 ， 则 将 一 直 不 过 期 ， 可 能 会 导致 脏 数 据 存在 很 长 时 间 (因此 ， 建 议 
设置 expireAfterWrite) 。 


缓存 回收 策略 /基于 Java 对 象 引 用 
weakKeys/weakValues: 设置 弱 引 用 缓存 。 
softValues: 设置 软 引 用 缓存 。 

缓存 回收 策略 /主动 失效 


invalidate(Object key)/ invalidateAll(Iterable<?> keys)/invalidateAll() : 
主动 失效 某 些 缓存 数据 。 


什么 时 候 触发 失效 呢 ? Guava Cache 不 会 在 缓存 数据 失效 时 立即 触发 回收 
操作 〈 如 果 要 这 么 做 ， 则 需要 有 额外 的 线程 来 进行 清理 ) ， 而 在 PUT 时 
会 主动 进行 一 次 缓存 清理 ， 当 然 读 者 也 可 以 根据 实际 业务 通过 目 己 设计 
线程 来 调用 cleanUp 方 法 进行 清理 。 


并 发 级 别 


concurrencyLevel : Guava Cache E = 了 ConcurrentHashMap 
concurrencyLevel 用 来 设置 Segment 数 量 ，concurrencyLevel 越 大 并 发 能 
越 强 。 


统计 命中 率 
recordStats: 启动 记录 统计 信息 ， 比 如 命中 率 等 。 
2.Ehcache 3.x 实 现 


本 文 使 用 最 新 的 Ehcache 3.1.2， 目 前 Ehcache 3.x 版 本 还 比较 新 ， 一 些 文档 
还 不 是 很 完善 。 


CacheManager cacheManager = CacheManagerBuilder. newCacheManagerBuilder(). 
build(true); 
CacheConfigurationBuilder<String, String» cacheConfig = 
CacheConfigurationBuilder.newCacheConfigurationBuilder( 
String.class, 
String.class, 
ResourcePoolsBuilder.newResourcePoolsBuilder() 
.heap(100, EntryUnit.ENTRIES)) 
.withDispatcherConcurrency (4) 


.withExpiry (Expirations.timeToLiveExpiration(Duration.of(10, 
TimeUnit.SECONDS) ) ) ; 


Cache<String, String» myCache = cacheManager.createCache ("myCache", 
cacheConfig) ; 


CacheManager 在 JVM 关 闭 时 调用 CacheManager.close() 方 法 ， 可 以 通过 
PUT ` GET2E i: 5; k ff. ° CacheConfigurationBuilder 也 有 几 类 参数 : 缓存 
回收 策略 、 并 发 设置 、 统 计 命 中 率 等 。 


缓存 回收 策略 /基于 容量 


heap(100, EntryUnit.ENTRIES) : 设置 缓存 的 条 目 数量 ， 当 超出 此 数量 
时 按照 LRU 进 行 缓存 回收 。 


缓存 回收 策略 /基于 空间 


heap(100, MemoryUnit.MB): 设置 缓存 的 内 存 空 间 ， 当 超出 此 空间 时 按 
照 LRU 进 行 缓存 回收 。 另 外 ， 应 该 设置 withSizeOfMaxObjectGraph(2) 统 计 
对 象 大 小 时 对 象 图 遍历 深度 和 withSizeOfMaxObjectSize(1, MemoryUnit.KB 
) 可 缓存 的 最 大 对 象 大 小 。 


缓存 回收 策略 /基于 时 间 


withExpiry(Expirations. timeToLiveExpiration (Duration. of (10, 
TimeUnit. SECONDS )): 设置 TITL， 没 有 TTI。 


withExpiry(Expirations. timeToIdleExpiration (Duration. of (10, TimeUnit. 
SECONDS )): 同时 设置 TTL 和 TTI， 且 TITL 和 TTI 值 一 样 。 


缓存 回收 策略 /主动 失效 


remove(K key)/ removeAll(Set<? extends K> keys)/clear(): 主动 失效 某 些 
缓存 数据 。 


什么 时 候 触 发 失效 呢 ? Ehcache 使 用 了 类 似 于 Guava Cache 的 机 制 。 

并 发 级 别 

目前 还 没有 提供 API 来 设置 ，Ehcache 内 部 使 用 ConcurrentHashMap 作 为 组 
存 存储 ， 默 认 并 发 级 别 16。withDispatcherConcurrency 是 用 来 设置 事件 分 
发 时 的 并 发 级 别 。 

统计 命中 率 

目前 还 没有 开放 API 来 统计 。 


3.MapDB 3.x 实 现 


HTreeMap myCache = 
DBMaker.heapDB().concurrencyScale(16).make().hashMap ("myCache") 
.expireMaxSize (10000) 

.expireAfterCreate(10, TimeUnit.SECONDS) 
.expireAfterUpdate(10, TimeUnit.SECONDS) 
.expireAfterGet(10, TimeUnit.SECONDS) 


.create(); 


然后 可 以 通过 PUT、GET 来 读 写 缓存 。 其 有 几 类 参数 : 缓存 回收 策略 、 并 
发 设置 、 统 计 命 中 率 等 。 


缓存 回收 策略 /基于 容量 

expireMaxSize: 设置 缓存 的 容量 ， 当 超出 expireMaxSize 时 ， 按 照 LRU 进 
行 缓存 回收 。 

缓存 回收 策略 /基于 时 间 


expireAfterCreate/expireAfterUpdate: 设置 TITL ， 绥 存 数 据 在 给 定 的 时 
间 内 没有 写 CERTES) 时 ， 则 被 回收 ， 即 定期 地 会 回收 缓存 数据 。 
expireAfterGet: 设置 TTI， 绥 存 数据 在 给 定 的 时 间 内 没有 人 被 读 / 写 时 ， 则 
被 回收 。 每 次 访问 时 都 会 更 新 它 的 TTI， 从 而 如 果 该 缓存 是 非常 热 的 数 
据 ， 则 将 一 直 不 过 期 ， 可 能 会 导致 脏 数 据 存在 很 长 的 时 间 (因此 ， 建 议 
要 设置 expireAfterCreate/expireAfterUpdate) 。 


缓存 回收 策略 /主动 失效 
remove(Object key) /clear(): 主动 失效 某 些 绥 存 数据 。 


什么 时 候 触 发 失效 呢 ? MapDB 默 认 使 用 类 似 于 Guava Cache 的 机 制 。 不 
过 ， 也 文 持 通 过 如 下 配置 使 用 线程 池 定 期 进行 缓存 失效 。 


.expireExecutor(scheduledExecutorService ) 
.expireExecutorPeriod(3000) 

并 发 级 别 

concurrencyScale: 类 似 于 Guava Cache 的 配置 。 
统计 命中 率 

EE 


还 可 以 使 用 DBMakermemoryDB0O 创 建 堆 绥 存 ， 它 将 数据 序列 化 并 存储 到 
1MB 大 小 的 byte[] 数 组 中 ， 从 而 减少 垃圾 回收 的 影响 。 


9.4.2 ” 堆 外 缓存 
1.EhCache 3.x 实 现 


CacheConfigurationBuilder<String, String> cacheConfig = 


CacheConfigurationBuilder.newCacheConfigurationBuilder ( 

String.class, 

String.class, 

ResourcePoolsBuilder.newResourcePoolsBuilder() 

.offheap(100, MemoryUnit.MB)) 

.withDispatcherConcurrency (4) 

.WithExpiry(Expirations.timeToLiveExpiration(Duration.of(10, 
TimeUnit.SECONDS))) 

.withSizeOfMaxObjectGraph (3) 

.WwithSizeOfMaxObjectSize(1, MemoryUnit. KB) ; 


堆 外 缓存 不 文 持 基于 容量 的 缓存 过 期 策略 。 


2.MapDB 3.x 实 现 


HTreeMap myCache = 


DBMaker.memoryDirectDB().concurrencyScale(16).make().hashMap ("myCache") 
.expireStoreSize(64 * 1024 * 1024) // 指 定 堆 外 缓存 大 小 64MB 
.expireMaxSize (10000) 

.expireAfterCreate(10, TimeUnit.SECONDS) 
.expireAfterUpdate(10, TimeUnit. SECONDS) 
.expireAfterGet (10, TimeUnit. SECONDS) 
.create(); 


在 使 用 堆 外 缓存 时 ， 请 记得 添加 JVM 局 动 参数 ， 如 - 
XX:MaxDirectMemorySize=10G ° 


9.4.3 BARE 


1.EhCache 3.x 实 现 


CacheManager cacheManager = CacheManagerBuilder. newCacheManagerBuilder() 
// 默 认 线 程 池 
.using(PooledExecutionServiceConfigurationBuilder 
.newPooledExecutionServiceConfigurationBuilder() 
.defaultPool("default", 1, 10).build()) 
// 磁 盘 文件 存储 位 置 
.with (new CacheManagerPersistenceConfiguration (new File("D:\\bak") ) ) 
.build(true); 


CacheConfigurationBuilder<String, String> cacheConfig = 


CacheConfigurationBuilder. newCacheConfigurationBuilder ( 
String.class, 


String.class, 
ResourcePoolsBuilder.newResourcePoolsBuilder() 
.disk(100, MemoryUnit.MB, true)) // 人 磁盘 缓存 
.withDiskStoreThreadPool ("default", 5) 
// 使 用 "default" 线 程 池 进行 dump 文件 到 磁盘 
.WithExpiry (Expirations.timeToLiveExpiration(Duration.of(50, 
TimeUnit.SECONDS))) 
.WithSizeOfMaxObjectGraph (3) 
.WithSizeOfMaxObjectSize(1, MemoryUnit.KB); 


在 JVM 停 止 时 ， 记 得 调用 cacheManager .close) ， 从 而 保证 内 存 数据 能 
dump Ri ° 


2.MapDB 3.x 实 现 


DB db = DBMaker 
. fileDB("D:\\bak\\a.data") // 数 据 存 哪里 
.fileMmapEnable() // 启 用 mmap 
.fileMmapEnableIfSupported() // 在 支持 的 平台 上 启用 mmap 
.fileMmapPreclearDisable() //ikmmap 文件 更 快 
.cleanerHackEnable() // 一 些 BUG 处 理 
.transactionEnable() // 启 用 事务 
.CloseOnJvmShutdown () 
.ConcurrencyScale (16) 
.make (); 


HTreeMap myCache = db.hashMap ("myCache") 
.expireMaxSize (10000) 
.expireAfterCreate (10, TimeUnit. SECONDS) 
.expireAfterUpdate (10, TimeUnit.SECONDS) 
.expireAfterGet (10, TimeUnit. SECONDS) 
.CreateOrOpen(); 


因为 开启 了 事务 ，MapDB 则 开启 了 WAL。 另 外 ， 操 作 完 缓存 后 记得 调用 
db.commit 方 法 提交 事务 。 


myCache.put(" key" + counterWriter, "value" + counterWriter); 


db .commit(); 


9.4.4 “分 布 式 缓存 


本 文 使 用 Ehcache 3.1+Terracotta server 实 现 ，Ehcache 3.15] 入 了 一 个 下 载 
套件 ， 其 包含 了 Terracotta Server ° 


Ehcache 3 with clustering Support 


Ehcache 3.1 (with clustering) kit .zip 


a |. ehcache-clustered-3.1.2-kit 
> |) client 
J legal 


4 出 server 
E bin 
lib 


> }) plugins 


start-tc-server.bat 
start-tc-server.sh 


| tc-config.xml 


调用 start-tc-server 脚 本 启动 tc server ° 


1. 架 构 


应 用 1 中 用 2 
e E 
MESH E 堆 外 缓存 
— | 
分 布 式 缓存 分 布 式 缓存 


Terracotta Server Terracotta Server 
active standby 


2.Terracotta Server 配 置 


<?xml version="1.0" encoding-"UTF-8"?» 
<tc-config xmlns="http://www.terracotta.org/config" 


xmlns:ohr="http://www.terracotta.org/config/offheap-resource"> 


«servers» 
«server host-"192.168.147.50" name-"s1"» 
<tsa-port>9510</tsa-port> 
<tsa-group-port>9530</tsa-group-port> 
</server> 


<server host="192.168.147.52" name="s2"> 
<tsa-port>9510</tsa-port> 
<tsa-group-port>9530</tsa-group-port> 
</server> 


<client-reconnect-window>30</client-reconnect-window> 
<restartable enabled="true"/> 


</servers> 


<services> 
<service id="resources"> 
<ohr:offheap-resources> 
<ohr:resource name-"cache" unit="MB">64</ohr:resource> 
</ohr:offheap-resources> 
</service> 
</services> 
</tc-config> 


配置 了 两 个 tc server， 一 主 一 备 。 在 两 台 服 务 器 中 分 别 调用 如 下 脚本 局 动 


fte server ° 
./start-tc-server.sh -f tc-config.xml -n s1 


./start-tc-server.sh -f tc-config.xml -n s2 


3.Ehcache 代 码 片段 


CacheManagerBuilder<PersistentCacheManager> 
clusteredCacheManagerBuilder = 
CacheManagerBuilder.newCacheManagerBuilder() 
.with (ClusteringServiceConfigurationBuilder.cluster(URI.create ( 
"terracotta: //192.168.147.50:9510") ) . readOperationTimeout (500, 
TimeUnit.MILLISECONDS) .autoCreate()); 


final PersistentCacheManager cacleManager = cdusteredCacheManagerBuilder. 
build(true); 


Cache<String, String» myCache = cacheManager.createCache ("myCache", 
CacheConfigurationBuilder.newCacheConfigurationBuilder( 


String.class, 
String.class, 
ResourcePoolsBuilder.newResourcePoolsBuilder() 
.with (ClusteredResourcePoolBuilder 
.clusteredDedicated( 

"cache", 32, MemoryUnit.MB))) 
.WithDispatcherConcurrency (4) 
.WithExpiry(Expirations.timeToLiveExpiration(Duration.of 

(10, TimeUnit.SECONDS)))); 


可 以 看 到 一 个 问题 ， 此 处 只 指定 了 IP 为 192.168.147.50 这 台 机 器 的 tc 
server， 那 么 当 50 这 人 台 机 器 挂 了 时 ， 目 前 是 不 能 目 动 连接 到 52 机 器 的 。 不 
aaa 或 者 可 以 考虑 使 用 其 主打 产品 BigMemory 


对 于 分 布 式 缓存 个 人 还 是 喜欢 使 用 Redis 之 类 的 ， 性 能 也 非常 好 ， 有 主 从 
模式 、 和 集群 模式 。 目 前 不 建议 使 用 Ehcache 3.1+Terracotta server 组 合 。 


9.45 ”多 级 缓存 


如 先 查 找 扒 缓存 ， 如 果 没 有 则 得 找 磁盘 缓存 ， 那 么 使 用 MapDB 通 过 如 下 
配置 实现 。 


HTreeMap diskCache = db.hashMap ("myCache") 
.expireStoreSize(8 * 1024 * 1024 * 1024) 
.expireMaxSize (10000) 
.expireAfterCreate(10, TimeUnit. SECONDS) 
.expireAfterUpdate(10, TimeUnit. SECONDS) 
.expireAfterGet(10, TimeUnit.SECONDS) 
.createOrOpen(); 


HTreeMap heapCache = db.hashMap ("myCache") 
.expireMaxSize (100) 
.expireAfterCreate(10, TimeUnit. SECONDS) 
.expireAfterUpdate(10, TimeUnit. SECONDS) 
.expireAfterGet(10, TimeUnit. SECONDS) 
.expireOverflow(diskCache) // 当 缓存 溢出 时 存储 到 disk 
.createOrOpen(); 


对 于 更 复杂 的 多 级 缓存 请 参考 “第 11 草 多 级 缓存 ”。 


9.5 ”应 用 级 缓存 示例 
9.5.1 多 级 缓存 API 封 装 


ee ee c7 
本 地 缓存 ， 以 提升 性 能 。 对 于 多 实例 的 情况 ， 不 仅 会 使 用 本 地 缓存 ， 还 
会 使 用 分 布 式 缓存 ， 因 此 需要 进行 适当 的 API 封 装 以 简化 缓存 操作 。 


1. 本 地 缓存 初始 化 


public class LocalCacheInitService extends BaseService { 
@Override 
public void afterPropertiesSet() throws Exception { 
// 商 品类 目 缓存 
Vince ia Object» categoryCache - 
CacheBuilder.newBuilder() 
.softValues () 
.maximumSize (1000000) 
.expireAfterWrite (Switches.CATEGORY.getExpiresInSe 
conds() / 2, TimeUnit. SECONDS) 
.build(); 
addCache (CacheKeys.CATEGORY KEY, categoryCache); 
) 


private void addCache (String key, Cache«?, ?> cache) { 


localCacheService.addCache(key, cache); 


} 
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缓存 时 间 太 长 造成 多 实例 间 的 数据 不 一 致 。 


另外 ， 将 缓存 key 前 缀 与 本 地 缓存 关联 ， 从 而 匹配 缓存 key 前 级， 就 可 以 
找到 相关 联 的 本 地 缓存 。 


2. 写 缓存 API 封 装 
先 写 本 地 缓存 ， 如 果 需 要 写 分 布 式 缓存 ， 则 通过 异步 更 新 分 布 式 缓存 。 


public void set(final String key, final Object value, 
final int remoteCacheExpiresInSeconds) throws RuntimeException { 
if (value == null) { 
return; 


} 


// 复 制 值 对 象 
// 本 地 缓存 是 引用 ， 分 布 式 缓存 需要 序列 化 
// 如 果 不 复制 的 话 ， 则 假设 数据 更 改 后 将 造成 本 地 缓存 与 分 布 式 缓存 不 一 至 
final Object finalValue = copy(value); 
// 如 果 配 置 了 写本 地 缓存 ， 则 根据 KEY 获得 相关 的 本 地 缓存 ， 然 后 写 入 
if (writeLocalCache) (| 
Cache localCache = getLocalCache (key); 
if (localCache != null) { 
localCache.put(key, finalValue); 
) 
) 
// 如 果 配 置 了 不 写 分 布 式 缓存 ， 则 直接 返回 
if (!writeRemoteCache) { 
return; 
) 
/ /异步 更 新 分 布 式 缓存 
asyncTaskExecutor.execute(() -> ( 
try { 
redisCache.set( 
key, 
JSONUtils.toJSON(finalValue), 
remoteCacheExpiresInSeconds); 
) catch (Exception e) ( 
LOG.error("update redis cache error, key : ()", key, e); 


此 处 使 用 了 异步 更 新 ， 目 的 是 尽快 返回 用 户 请 求 。 而 因为 有 本 地 缓存 ， 
所 以 部 使 分布 式 缓存 更 新 比较 慢 又 产生 了 回 源 ， 也 可 以 在 本 地 缓存 全 


3. 读 缓存 API 封 装 


先 读本 地 缓存 ， 本 地 缓存 不 命中 的 再 批量 碍 询 分 布 式 缓存 ， 在 查询 分 布 
式 缓存 时 通过 分 区 批量 查询 。 


private Map innerMget (List<String> keys, List<Class> types) 
throws Exception { 
Map<String, Object» result = Maps.newHashMap(); 
List<String> missKeys = Lists.newArrayList(); 
List<Class> missTypes = Lists.newArrayList(); 
// 如 果 配 置 了 读本 地 缓存 ， 则 先 读本 地 缓存 
if(readLocalCache) (| 
for (int i = 0; i < keys.size(); i++) { 

String key = keys.get (i); 

Class type = types.get(i); 

Cache localCache = getLocalCache (key); 

if (localCache != null) { 

Object value = localCache.getIfPresent (key); 


I 


result.put(key, value); 

if (value == null) { 
missKeys.add (key) ; 
missTypes.add(type) ; 

} 

} else { 
missKeys.add(key) ; 
missTypes.add (type); 


} 
// 如 果 配 置 了 不 读 分 布 式 缓存 ， 则 返回 
if(!readRemoteCache) { 
return result; 
} 
final Map<String, String» missResult = Maps.newHashMap() ; 


//Xt key 分 区 ， 不 要 一 次 性 批量 调用 太 大 
final List<List<String>> keysPage = Lists.partition(missKeys, 10); 
List<Future<Map<String, String>>> pageFutures = ListsewArrayList(); 


try ( 
// 批 量 获取 分 布 式 缓存 数据 
for (final List<String> partitionKeys : keysPage) { 
pageFutures.add (asyncTaskExecutor. submit ( 
() -> redisCache.mget (partitionKeys))); 
} 
for (Future<Map<String, String>> future : pageFutures) { 
missResult.putAll (future.get (3000, TimeUnit.MILLISECONDS) ) ; 


} 

} catch (Exception e) { 
pageFutures.forEach(future -> future.cancel (true) ); 
throw e; 

} 

//@# result 和 missResult， 此 处 实现 省 略 

return result; 


此 处 将 批量 读 缓存 进行 了 分 区 ， 防 止 乱用 批量 获取 API。 
9.5.2 NULL Cache 

首先 ， 定 义 NULL 对 象 。 

private static final String NULL_STRING = new String(); 

当 DB 没 有 数据 时 ， 写 入 NULL 对 象 到 缓存 。 


/ /查询 DB 
String value = loadDB(); 
// 如 果 DB 没有 数据 ， 则 将 其 封装 为 NULL STRING 并 放 入 绥 存 
if(value == null) { 
value = NULL STRING; 
} 
myCache.put (id, value); 


读 取 数据 时 ， 如 果 发 现 NULL 对 象 ， 则 返回 null， 而 不 是 回 源 到 DB 。 


value = suitCache.getIfPresent(id); 
/ /DB 没有 数据 ， 返 回 null 
if (value == NULL STRING) (| 

return null; 


) 
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情况 。 


9.5.3 ”强制 获取 最 新 数据 


在 实际 应 用 中 ， 我 们 经 常 需 要 强制 更 新 数据 ， 此 时 了 束 不 能 使 用 缓存 数据 
了 ， 可 以 通过 配置 ThreadLocal 开 关 来 决定 是 否 强制 刷新 缓存 (refresh 方法 
要 配合 CacheLoader 一 起 使 用 ) 。 


if (ForceUpdater.isForce UpdateMyInfo ()) 1 


myCache.refresh(skuId); 


} 
String result = myCache.get(skuId); 
if(result == NULL_STRING) { 

return null; 


} 


95.4 ”失败 统计 


private LoadingCache<String, AtomicInteger> failedCache = 
CacheBuilder.newBuilder() 
.softValues () 
.maximumSize (10000) 
.build(new CacheLoader<String, AtomicInteger>() { 
@Override 
public AtomicInteger load(String skuId) throws Exception { 
return new AtomicInteger(0); 
) 
); 


当 失 败 时 ， 通 过 failedCache.getUnchecked(id).incrementAndGetO 增 加 失败 

次 数 ; 当成 功 时 ， 使 用 failedCache.invalidate(id) 使 缓存 失效 。 通 过 这 种 方 

nua n um "而且 当 内 存 不 足 时 ， 绥 存 数据 可 以 被 垃圾 回 
了 [B 


9.5.5 “延迟 报警 


private static LoadingCache<String, Integer» alarmCache = 
CacheBuilder.newBuilder() 
.softValues () 
.maximumSize (10000) .expireAfterAccess(1, TimeUnit.HOURS) 
.build(new CacheLoader<String, Integer>() { 
@Override 
public Integer load(String key) throws Exception { 
return 0; 
} 
); 


// 报 警 代码 
Integer count = 0; 
if(redis !- null) { 


String countStr = 
Objects. firstNonNull (redis.opsForValue().get(key), "0"); 
count = Integer. valueOf(countStr) ; 


} else { 
count = alarmCache.get (key); 
} 
if(count $ 5 == 0) ( //5 次 报 一 次 
// 报 警 


) 


count = count + 1; 


if(redis != null) { 
redis.opsForValue().set(key, String.valueOf(count), 
1, TimeUnit. HOURS) ; 
} else { 


alarmCache.put(key, count); 
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以 考虑 N 久 报警 了 M 次 ， 才 真正 报警 。 此 时 ， 也 可 以 使 用 Cache 来 统计 。 
本 示例 还 加 入 了 Redis 分 布 式 缓存 记录 支持 。 


9.6 ”缓存 使 用 模式 实践 


前 面 已 经 介绍 了 Java 缓 存 的 使 用 。 对 于 我 们 来 说 ， 如 条 有 人 已 总 结 出 一 些 
缓存 使 用 模式 /模板 ， 我 们 在 使 用 时 直接 照搬 模式 即 可 。 确 实 已 经 有 总 结 


好 的 模式 ， 主 要 分 两 大 类 : Cache-AsidefliCache-As-SoR (Read-through ^ 
Write-through、Write-behind) ° 
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SoR (system-of-record) : 记录 系统 ， 或 者 可 以 叫做 数据 源 ， 即 实际 存 
储 原始 数据 的 系统 。 


Cache: 缓存， 是 SoR 的 快照 数据 ，Cache 的 访问 速度 比 SoR 要 快 ， 放 入 
Cache 的 目的 是 提升 访问 速度 ， 减 少 回 源 到 SoR 的 次 数 。 


回 源 : 即 回 到 数据 源头 获取 数据 ，Cache 没 有 命中 时 ， 需 要 从 SoR 读 取 数 
据 ， 这 叫做 回 源 。 


本 文 主 要 以 Guava Cache 和 Ehcache3.x 作 为 实践 框架 来 讲解 。 
9.6.1 Cache-Aside 


Cache-Aside 即 业务 代码 围绕 着 Cache 写 ， 是 由 业务 代码 直接 维护 缓存 ， 示 
例 代码 如 下 所 示 。 


//1. 先 从 缓存 中 获取 数据 


value = myCache.getIfPresent(key); 


if(value == null) { 
//2.1. 如 果 绥 存 没 有 命中 ， 则 回 源 到 son 获取 源 数据 
Value = loadFromSoR (key); 
//2.2. 将 数据 放 入 缓存 ， 下 次 即 可 从 缓存 中 获取 数据 
myCache.put(key, value); 

} 


读 场 景 ， 允 从 缓存 获取 数据 ， 如 果 没 有 命中 ， 则 回 源 到 SoR 并 将 源 数 据 放 
入 缓存 供 下 次 读 取 使 用 。 


写 场景 ， 允 将 数据 写 入 SoR， 写 入 成 功 后 立即 将 数据 同步 写 入 缓存 。 
/1. 先 将 数据 写 入 SoR 
writeToSoR (key, value); 


I2 .执行 成 功 后 立即 同步 写 入 缓存 


myCache.put(key, value); 
PE 写 入 成 功 后 将 缓存 数据 过 期 ， 下 次 读 取 时 再 加 载 
BAF ° 


IA CERIS ASOR 

writeToSoR (key, value); 

/2. 失 歼 缓存 ， 然 后 下 次 读 时 再 加 载 缓 存 
myCache.invalidate(key); 


Cache-Aside 适 合 使 用 AOP 模 式 去 实现 ， 具 体操 作 可 以 参考 笔者 的 博客 
《Spring Cache 抽 象 详解 》。 


对 于 Cache-Aside， 可 能 存在 并 发 更 新 情况 ， 即 如 果 多 个 应 用 实例 同时 更 
BM, DARA EAI? 


.如果 是 用 户 维度 的 数据 (如 订单 数据 、 用 户 数 据 ) ， 这 种 几率 非常 小 ， 
T 可 以 不 考虑 这 个 问题 ， 加 上 过 期 时 间 来 解决 即 
HI o 


- 对 于 如 商品 这 种 基础 数据 ， 可 以 考虑 使 用 canal 订 阅 binlog， 来 进行 增 量 
更 新 分 布 式 缓存 ， 这 样 不 会 存在 缓存 数据 不 一 致 的 情况 。 但 是 ， 缓 存 更 
新 会 存在 延迟 。 而 本 地 缓存 可 根据 不 一 致 容忍 度 设置 合理 的 过 期 时 间 。 


` 读 服 务 场景 ， 可 以 考虑 使 用 一 致 性 哈 希 ， 将 相同 的 操作 负载 均衡 到 同一 
个 实例 ， 从 而 减少 并 发 几率 。 或 者 设置 比较 短 的 过 期 时 间 ， 可 参考 “第 17 
章 系 东 商品 详情 页 服务 闭环 实践 ”。 


9.6.2 Cache-As-SoR 

Cache-As-SoR 即 把 Cache 看 作为 SoR， 所 有 操作 都 是 对 Cache 进 行 ， 然 后 
Cache 再 委托 给 SoR 进 行 真 实 的 读 / 写 。 即 业务 代码 中 只 看 到 Cache 的 操 
作 ， 看 不 到 关于 SoR 相 关 的 代码 。 有 三 种 实现 : read-through ^ write- 


through ^ write-behind ° 


9.6.3 Read-Through 


Read-Through， 业 务 代码 首先 调用 Cache， 如 果 Cache 不 命中 由 Cache 回 源 
到 SoR， 而 不 是 业务 代码 ( 即 由 Cache 读 SoR) 。 使 用 Read-Through 模 式 ， 
需要 配置 一 个 CacheLoader 组 件 用 来 回 源 到 SoR 加 和 载 源 数据 。Guava Cache 
和 Ehcache 3.x 都 文 持 该 模式 。 


1.Guava Cache 实 现 


LoadingCache«Integer, Result<Category>> getCache = 


CacheBuilder.newBuilder() 

.softValues () 

.maximumSize (5000) .expireAfterWrite(2, TimeUnit.MINUTES) 

.build(new CacheLoader<Integer, Result<Category>>() { 
@Override 
public Result<Category> load(final Integer sortId) 

throws Exception { 
return categoryService.get(sortId); 


FJa 


在 build Cache 时 ， 传 入 一 个 CacheLoader 用 来 加 载 缓存 ， 操 作 流程 如 下 。 

(1) 应 用 业务 代码 直接 调用 getCache .get(sortId) 。 

(2) 首先 查询 Cache， 如 果 缓 存 中 有 ， 则 直接 返回 缓存 数据 。 

(3) 如果 缓 存 没 有 命中 ， 则 委托 给 CacheLoader ，CacheLoader 会 回 源 到 
SoR 查 询 源 数据 〈 返 回 值 必须 不 为 nuall， 可 以 包装 为 Nul 对 象 ) ， 然 后 写 
入 缓存 。 

使 用 CacheLoader 后 有 几 个 好 处 。 

. 应 用 业务 代码 更 简洁 了 ， 不 需要 像 Cache-Aside 模 式 那 样 缓存 查询 代码 和 
SoR 人 代码 交织 在 一 起 。 如 果 绥 存 使 用 逻辑 散落 在 多 处 ， 则 使 用 这 种 方式 很 
简单 地 消除 了 重复 代码 。 

- 解决 Dog-pile effect， 即 当 某 个 缓存 失效 时 ， 又 有 大 量 相同 的 请 求 没命 中 


缓存 ， 从 而 使 请 求 同 时 到 后 端 ， 导 致 后 端庄 力 太 大 ， 此 时 限定 一 个 请 求 
去 拿 即 可 。 


if (firstCreateNewEntry) {// 第 一 个 请 求 加 载 缓存 的 线程 去 SoR 加 载 源 数据 
try { 
synchronized (e) { 
return loadSync(key, hash, loadingValueReference, loader); 
} 
) finally { 
statsCounter.recordMisses (1); 
) 
) else {// 其 他 并 发 线程 等 待 “ 第 一 个 线程 ”加 载 的 数据 


return waitForLoadingValue(e, key, valueReference); 


Guava Cacheif x fT get(K key, Callable<? extends V> valueLoader) 方 法 ， 传 
入 一 个 Callable 实 例 ， 当 缓存 没命 中 时 ， 会 调用 Callable#call 来 查询 SoR 加 
载 产 数据 。 


2.Ehcache 3.x 实 现 


CacheManager cacheManager = 
CacheManagerBuilder. newCacheManagerBuilder(). build(true); 
org.ehcache.Cache«String, String» myCache - 
cacheManager. createCache ("myCache", 
CacheConfigurationBuilder 
.newCacheConfigurationBuilder ( 
String.class, String.class, 
ResourcePoolsBuilder.newResourcePoolsBuilder() 
.heap(100, MemoryUnit.MB)) 
.withDispatcherConcurrency (4) 
.withExpiry (Expirations.timeToLiveExpiration(Duration.of 
(10, TimeUnit.SECONDS))) 
-withLoaderWriter ( 
new DefaultCacheLoaderWriter<String, String> () { 
@Override 
public String load(String key) throws Exception { 
return readDB (key); 
) 
@Override 
public Map<String, String> loadAll(Iterable«?extends 


String> keys) throws BulkCacheLoadingException, Exception { 
return null; 
} 
))); 


Ehcache 3.x f£ Hj CacheLoaderWriter 来 实现， 通过 loadK key) 和 
loadAll(Iterable<? extends K> keys) 分 别 来 加 载 单 个 key 和 批量 key。 
Ehcache 3.1 没 有 上 自己 去 解决 Dog-pile effect ° 


9.6.4 Write-Through 


Write-Through， 被 称 为 穿 透 写 模式 / 直 写 模式 一 一 业务 代码 首先 调用 Cache 
写 (新 增 /修改 ) 数据 ， 然 后 由 Cache 负 责 写 缓存 和 写 SoR， 而 不 是 由 业务 
代码 。 使 用 Write-Through 模 式 需要 配置 一 个 CacheWriter 组 件 用 来 回 写 
SoR ° Guava Cache 没 有 提供 支持 。Ehcache 3.x Xx EZ X ° Ehcaches 
配置 一 个 CacheLoaderWriter，CacheLoaderWriter 知 道 如 何 去 写 SoR。 当 
Cache 需 要 写 (新 增 /修改 ) 数据 时 ， 首 先 调 用 CacheLoaderWriter 来 ( 立 
即 ) 同步 到 SoR， 成 功 后 会 更 新 缓存 。 


CacheManager cacheManager = 
CacheManagerBuilder.newCacheManagerBuilder ().build(true); 
org.ehcache.Cache<String, String> myCache = 
cacheManager.createCache ("myCache", 
CacheConfigurationBuilder 
.newCacheConfigurationBuilder(String.class, String.class, 
ResourcePoolsBuilder.newResourcePoolsBuilder() 
.heap(100, MemoryUnit.MB)) 
.withDispatcherConcurrency (4) 
.WithExpiry (Expirations.timeToLiveExpiration(Duration.of( 
10, TimeUnit. SECONDS) ) ) 
.withLoaderWriter ( 
new DefaultCacheLoaderWriter<String, String> () { 
@Override 
public void write(String key, String value) 
throws Exception { 
//write 


} 
@Override 
public void writeAll(Iterable<? extends Map.Entry<? 


extends String, ?extends String>> entries) throws BulkCacheWritingException, 
Exception { 
for (Object entry : entries) { 
//batch write 


} 
@Override 
public void delete(String key) throws Exception { 


//delete 
} 


@Override 
public void deleteAll(Iterable«? extends String> keys) 


throws BulkCacheWritingException, Exception { 
for (Object key : keys) { 
//batch delete 


} 
)) .build()); 


Ehcache 3.x if Æ fi Fl CacheLoaderWriter X Sz I, 38b 3X write(String key, 
String value) ^ writeAll(Iterable<? extends Map.Entry<? extends String, ? 


extends String>> entries) 和 delete(String key) ^ deleteAll(Iterable<? extends 
String> keys) 分 别 来 文 持 单 个 写 、 批 量 写 和 单个 删除 、 批 量 删 除 操 作 。 操 
作 流 程 如 下 。 


1. 当 我 们 调用 myCache.put("e", "123") 8% 4 myCache.putAll(map) f}, 4 2% 
D 


2. 首 先 ，Cache 会 将 写 操 作 立 即 委 托 给 CacheLoaderWriter#write 和 
#writeAll， 然 后 由 CacheLoaderWriter 负 责 立 即 去 写 SoR。 


3. 当 写 SoR 成 功 后 ， 再 写 入 Cache 。 


9.6.5 Write-Behind 


Write-Behind, ， 也 叫 Write-Back ， 我 们 称 之 为 回 写 模式 。 不 同 于 Write- 
Through 是 同步 写 SoR 和 Cache，Write-Behind 是 异步 写 。 异 步 之 后 可 以 实 
现 批量 写 、 合 并 写 、 延 时 和 限 流 。 


1.52258 


CacheManager cacheManager = CacheManagerBuilder. newCacheManagerBuilder() 
.using(PooledExecutionServiceConfigurationBuilder 
.DnewPooledExecutionServiceConfigurationBuilder() 
.pool("writeBehindPool", 1, 5) 
.build()) 
.build(true); 
org.ehcache.Cache«String, String» myCache = 
cacheManager. createCache ("myCache", 


CacheConfigurationBuilder 

.newCacheConfigurationBuilder(String.class, String.class, 
ResourcePoolsBuilder.newResourcePoolsBuilder() 

.heap(100, MemoryUnit.MB)) 
.withDispatcherConcurrency (4) 
.WithExpiry (Expirations.timeToLiveExpiration(Duration.of 
(10, TimeUnit.SECONDS))) 
.withLoaderWriter ( 
new DefaultCacheLoaderWriter<String, String >() { 


@Override 
public void write(String key, String value) 
throws Exception { 


//write 


@Override 
public void delete(String key) throws Exception { 
//delete 


}) 

.add (WriteBehindConfigurationBuilder 
.newUnBatchedwWriteBehindConfiguration() 
.queueSize (5) 

.concurrencyLevel (2 
.useThreadPool ("writeBehindPool") 
oun dg0))4 


几 个 重要 配置 如 下 。 


- ThreadPool: ”使 用 PooledExecutionServiceConfigurationBuilder 配 置 线程 
ih; 然后 WriteBehindConfigurationBuilder 通 过 useThreadPool 配 置 使 用 哪 一 


个 线程 池 。 
- WriteBehindConfigurationBuilder: 配置 WriteBehind 策 略 。 
: CacheLoaderWriter: 配置 WriteBehind 如 何 操作 SoR ° 


WriteBehindConfigurationBuilder 会 进行 如 下 几 个 配置 。 


: newUnBatchedWriteBehindConfiguration: ”表示 不 进行 批量 处 理 。 如 配 
置 ， 那 么 所 有 批量 操作 都 将 会 转换 成 单个 操作 ， 即 CacheLoaderWriter 只 


需要 实现 write 和 delete 即 可 。 


- queueSize(int size): ”因为 操作 是 异步 回 写 SoR， 需 要 将 操作 先 放 入 写 操 
作 等 竺 队列 。 因 此 ， 可 使 用 queue size 定 义 写 操作 等 竺 队列 最 大 大 小 ， 即 
线程 池 队 列 大 小 。 内 部 使 用 NonBatchingLocalHeapWriteBehindQueue ° 


- concurrencyLevel(int concurrency): 配置 使 用 多 少 个 并 发 线程 和 队列 进行 
WriteBehind。 因 为 我 们 只 传 入 一 个 线程 池 ， 是 如 何 实现 该 模式 的 呢 ? B 
先 看 如 下 代码 片段 。 


for (int i = 0; i < writeBehindConcurrency; i++) { 
if (config.getBatchingConfiguration() == null) { 
this.stripes.add( 
new NonBatchingLocalHeapWriteBehindQueue«K, V»( 
executionService, defaultThreadPool, 
config, cacheLoaderWriter)); 
) else { 
this.stripes.add( 
new BatchingLocalHeapWriteBehindQueue«K, V»( 
executionService, defaultThreadPool, 
config, cacheLoaderWriter)); 


可 以 看 到 ， 会 fi] Æ concurrency level 个 队 列 
NonBatchingLocalHeapWriteBehindQueue， 其 又 通过 如 下 代码 片段 创建 线 
程 池 和 线程 池 队 列 。 


this.executorQueue = 
new LinkedBlockingQueue«Runnable» (config. getMaxQueueSize()); 
if (config.getThreadPoolAlias() == null) { 
this.executor = executionService.getOrderedExecutor ( 
defaultThreadPool, executorQueue) ; 
} else { 
this.executor = executionService.getOrderedExecutor ( 
config. getThreadPoolAlias(), executorQueue) ; 


- CacheLoaderWriter: 此 处 我 们 只 配置 了 write 和 delete i writeAll il 
deleteAll 将 会 把 批量 操作 委托 给 write 和 delete。 


PooledExecutionService#getOrderedExecutor 7; 法 会 创 建 
PartitionedOrderedExecutor 实 例 。 


PartitionedOrderedExecutor ( 
BlockingQueue<Runnable> queue, ExecutorService executor) { 
this.delegate = new PartitionedUnorderedExecutor (queue, executor, 1); 


} 


其 使 用 maxWorkers=1 创 建 了 PartitionedUnorderedExecutor， 然 后 Partitioned 
UnorderedExecutor 通 过 this.runnerPermit = new Semaphore(maxWorkers) 来 


控制 并 发 ， 即 maxWorkers=1 束 实现 了 一 个 并 发 。 

因此 ，Ehcache 实 际 能 写 的 最 大 队列 大 小 为 concurrency level * queue size。 

因为 内 部 使 用 线程 池 去 写 ， 因 此 束 实 现 了 异步 写 ， 又 因为 使 用 了 队列 ， 

因此 控制 了 总 的 吞吐 量 〈 此 处 要 注意 根据 实际 场景 给 线程 池 配置 Rejected 
Policy) ， 接 下 来 看 一 下 如 何 实现 批量 写 。 


2. 批 量 写 


.withLoaderWriter (new DefaultCacheLoaderWriter<String, String>() { 
@Override 
public voidwriteAll (Iterable<? extends Map.Entry<? extends String, ? 
extends String>> entries) throws BulkCacheWritingException, Exception { 
for (Object entry : entries) { 
//batch write 


} 
@Override 
public void deleteAll(Iterable<? extends String> keys) throws 
BulkCacheWritingException, Exception { 
for (Object key : keys) { 
//batch delete 


}) 

.add (WriteBehindConfigurationBuilder 
.newBatchedWriteBehindConfiguration(3, TimeUnit.SECONDS, 2) 
.queueSize (5) 

.concurrencyLevel (1) 
.enableCoalescing () 
.useThreadPool ("writeBehindPool") 
build ())) 


和 上 一 个 示例 不 同 的 地 方 是 使 用 了 newBatchedWriteBehindConfiguration 进 
行 批量 配置 。 


newBatchedWriteBehindConfiguration(long maxDelay, TimeUnit 
maxDelayUnit, int batchSize): 设置 批 处 理 大 小 和 最 大 延迟 。batchSize 用 于 
定义 批 处 理 大 小 ， 当 写 操作 数量 等 于 批 处 理 大 小 时 ， 将 把 这 一 批 数 据 发 
给 CacheLoaderWriter 进行 处 FE 。 Ehcache 使 用 
BatchingLocalHeapWriteBehindQueue 实 现 批 量 队 列 ， 其 中 操作 批量 的 代码 
如 下 。 


if (openBatch.add(operation)) {// 往 batch 里 添加 操作 ， 添 加 的 数量 等 于 批 处 理 大 小 时 
submit (openBatch) ; // 异 步 提交 批 处 理 操作 
openBatch = null; 

) 


此 ，Ehcache 实 际 能 写 的 最 大 队列 大 小 为 concurrency level * queue size * 
batch size。 


maxDelay 用 于 配置 未 完成 的 批 处 理 最 大 延迟 ， 比 如 ， 我 们 设置 批 处 理 大 
小 为 3， 而 我 们 实际 只 写 入 了 两 个 数据 ， 当 写 第 3 个 数据 时 ， 会 触发 提交 
批 处 理 操作 。 但 是 ， 如 果 我 们 不 写 第 3 个 ， 那 么 将 造成 这 2 个 数据 一 直 等 
等 ， 我 们 可 以 设置 maxDelay， 当 超时 时 也 会 将 这 两 个 数据 提交 批 处 理 。 


-enableCoalescing: 是 否 需 要 合并 写 ， 即 对 于 相同 的 key 只 记录 最 后 一 次 
数据 。 


: CacheLoaderWriter: write 和 delete 会 转换 为 writeAl 和 deleteAl， 即 批 
处 理 。 


9.6.6 Copy Pattern 


有 两 种 Copy Pattern, Copy-On-Read (在 读 时 复制 ) 和 Copy-On-Write (在 
写 时 复制 ) ， 在 Guava Cache 和 Ehcache 中 堆 绥 存 都 是 基于 引用 的 ， 这 样 如 
果 有 人 拿 到 缓存 数据 并 修改 了 它 ， 则 可 能 发 生 不 可 预测 的 问题 ， 笔 者 就 
见 过 因为 这 种 情况 造成 数据 错误 。Guava Cache 没 有 提供 支持 ，Ehcache 
3.x 提 供 了 文 持 。 


public interface Copier<T> { 

T copyForRead(T obj); //Copy-On-Read, ltllmyCache.get () 

T copyForWrite(T obj); //Copy-On-Write, KUN myCache. put () 
} 


通过 如 下 方法 来 配置 key 和 Value 的 Copier。 
CacheConfigurationBuilder.withKeyCopier() 


CacheConfigurationBuilder.with ValueCopier() 


9.7 ”性 能 测试 
笔者 使 用 JMH 1.14 进 行 基准 性 能 测试 ， 比 如 测试 写 。 
@Benchmark 


@Warmup(iterations = 10, time = 10, timeUnit = TimeUnit.SECONDS ) 


@Measurement (iterations = 10, time = 10, timeUnit = TimeUnit. SECONDS) 
@BenchmarkMode (Mode. Throughput) 
@OutputTimeUnit (TimeUnit. SECONDS) 
@Fork (1) 
public void test 1 Write() { 
counterWriter = counterWriter + 1; 
myCache.put ("key" + counterWriter, "value" + counterWriter) ; 


) 


使 用 JMH 时 首先 进行 JVM 预 热 ， 然 后 进 
用 吞吐 量 ) 。 建 议 读者 按照 需求 进行 基 
缓存 框架 。 
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10 ” HTTP 缓存 
10.1 简介 


遇 到 很 多 人 咨询 笔者 关于 浏览 器 缓存 的 一 些 问题 ， 而 这 些 问 题 都 是 类 似 
的 ， 本 章 内 容 就 是 用 来 解答 以 后 会 遇 到 的 类 似 问题 


因 本 章 主 要 以 浏览 器 缓存 场景 来 介绍 ， 所 以 非 浏 览 器 场景 下 的 一 些 用 法 
本 章 不 会 介绍 ， 而 且 本 章 以 Chrome 为 测试 浏览 器 。 


浏览 器 缓存 是 指 当 我 们 使 用 浏 咒 器 访问 一 些 网 站 页 面 或 者 HTTP 服 务 时 ， 
根据 服务 右 端 返回 的 缓存 设置 响应 头 将 响应 内 容 缓 存 到 浏览 融 ， 下 次 可 
以 直接 使 用 缓存 内 容 或 者 仅 需要 去 服务 器 端 验 证 内 容 是 否 过 期 即 可 。 这 
样 的 好 处 是 可 以 减少 浏览 器 和 服务 器 端 之 间 来 回 传输 的 数据 量 ， 节 省 带 
宽 以 提升 性 能 


首先 看 个 例子 ， 当 我 们 第 一 次 访问 http:Witem.jd.com/1856588.html 时 ， 将 
得 到 如 下 响应 头 。 


Y General 
Request URL: http://item.jd.com/1856588.html 
Request Method: GET 
Status Code: @ 200 OK 
Remote Address: 111.206.231.1:80 


V Response Headers 
Age: 3 
Cache-Control: max-age=68 
Connection: keep-alive 
Content-Encoding: gzip 
Content-Type: text/html; charset=gbk 
Date: Tue, 16 Aug 2016 12:07:44 GMT 
Expires: Tue, 16 Aug 2016 12:08:23 GMT 
Last-Modified: Tue, 16 Aug 2016 12:07:25 GMT 
ser: 3.81 
Server: jdws 
Transfer-Encoding: chunked 
Vary: Accept-Encoding 
Via: BJ-Y-NX-111(HIT), http/1.1 B2J-UNI-1-2CS-116 ( [cSsStU]) 


接着 按 F5 刷 新 页 面 ， 将 得 到 如 下 啊 应 头 。 


Y General 
Request URL: http: //item.jd.com/1856588. html 
Request Method: GET 
Status Code: & 384 Not Modified 
Remote Address: 111.206.231.1:80 

Y Response Headers view source 
Cache-Control: max-age-68 
Connection: keep-alive 
Date: Tue, 16 Aug 2016 12:87:53 GMT 
Expires: Tue, 16 Aug 2016 12:08:23 GMT 
Server: jdws 
Vary: Accept-Encoding 
Via: http/1.1 BJ-UNI-1-2JCS-116 ( [cHs f ]) 


第 二 次 返回 的 相应 状态 码 为 304， 表 示 服 务 器 端 文档 没有 修改 过 ， 浏 览 圳 
缓存 的 内 容 还 是 最 新 的 。 


接 下 来 ， 我 们 看 一 下 如 何在 Java 应 用 层 控制 浏览 器 缓存 。 
10.2 HTTP 缓存 


10.2.1 Last-Modified 
如 下 是 我 们 的 spring mvc 组 存 测试 代码 。 


GRequestMapping ("/cache") 

public ResponseEntity<String> cache( 
// 浏 览 器 验证 文档 内 容 是 否 为 修改 时 传 入 的 Last-Modified 
@RequestHeader (value = "If-Modified-Since", required = false) 
Date ifModifiedSince) throws Exception { 


DateFormat gmtDateFormat = 
new SimpleDateFormat ("EEE, d MMM yyy HH:mm:ss 'GMT'! Locale US) ; 


// 文 档 最 后 修改 时 间 (去掉 毫秒 值 ) (为 方便 测试 ， 每 10 秒 生成 一 个 新 的 ) 
long lastModifiedMillis = getLastModified() / 1000 * 1000; 


// 当 前 系统 时 间 (去 掉 毫 秒 值 ) 

long now = System.currentTimeMillis() / 1000 * 1000; 
/文档 可 以 在 浏览 器 端 /proxy 上 缓存 多 久 【单位 : B 

long maxAge - 20; 


/ AME PS FE MERCY, bb fi FI EDT BT 


if (ifModifiedSince !- null 
&& ifModifiedSince.getTime() == lastModifiedMillis) ( 
MultiValueMap<String, String» headers = new HttpHeaders(); 
// 当 前 时 间 


headers.add("Date", gmtDateFormat. format (new Date(now))); 

// 过 期 时 间 http 1.0 支持 

headers.add("Expires", gmtDateFormat.format (new Date (now + mxAge 
* 1000) )); 

// 文 档 生 存 时 间 http 1.1 支持 

headers.add("Cache-Control", "max-age=" + maxAge); 

return new ResponseEntity<String> ( 

headers, HttpStatus.NOT MODIFIED); 


String body = "<a href=''> 点 击 访 问 当前 链接 </a>"; 

MultiValueMap<String, String» headers = new HttpHeaders(); 

// 当 前 时 间 

headers.add("Date", gmtDateFormat.format (new Date(now))); 

// 文 档 修改 时 间 

headers.add("Last-Modified", gmtDateFormat.format (new 
Date(lastModifiedMillis))); 

// 过 期 时 间 http 1.0 支持 

headers.add("Expires", gmtDateFormat.format (new Date (now + maxAge * 
1000))); 

// 文 档 生 存 时 间 http 1.1 支持 


headers.add("Cache-Control", "max-age-" + maxAge); 


return new ResponseEntity«String» (body, headers, HttpStatus.OK); 
} 


Cache«String, Long» lastModifiedCache = 
CacheBuilder.newBuilder() 
.expireAfterWrite(10, TimeUnit.SECONDS) .build(); 


public long getLastModified() throws ExecutionException { 
return lastModifiedCache. get ("lastModified", 


() -> { return System.currentTimeMillis(); }); 
} 


为 了 方便 测试 ， 文 档 的 修改 时 间 每 十 秒 更 新 一 次 ， 实 际 应 用 时 可 以 使 用 
如 商品 的 最 后 修改 时 间 等 替代 。 


1. 首 次 访问 


首次 访问 http:Wlocalhost:9080/cache， 将 得 到 如 下 啊 应 头 。 


Y General 
Request URL: http://localhost:9880/cache 
Request Method: GET 
Status Code: @ 200 
Remote Address: [::1]:9088 

Y Response Headers view source 
Cache-Control: max-age-28 
Content-Length: 39 
Content-Type: text/html;charset-UTF-8 
Date: Tue, 17 Jan 2817 89:21:13 GMT 
Expires: Tue, 17 Jan 2017 89:21:33 GMT 
Last-Modified: Tue, 17 Jan 2817 89:21:13 GMT 


响应 状态 码 200 表 示 请 求 内 容 成 功 ， 另 外 ， 有 如 下 几 个 缓存 控制 参数 。 


oo 表示 文档 的 最 后 修改 时 间 ， 当 去 服务 器 验证 时 会 用 到 这 
METTE] ° 


"Expires: http/1.03L1B EX, RANMA as PALATE, DIRE 
AAR HERAA, DUIS SE OA IR OS RACHA o 


: Cache-Control : http/1.1 规 范 定 义 ， 表 示 浏 虎 器 缓存 控制 ，max-age=20 
表示 文档 可 以 在 浏览 器 中 缓存 20 秒 。 


根据 规范 定义 Cache-Control 优 先 级 高 于 Expires。 实 际 使 用 时 可 以 两 个 都 
用 ， 或 仅 使 用 Cache-Control 束 可 以 了 (比如 京东 的 活动 页 sale.jd.com) ° 
一 般 情况 下 Expires= 当 前 系统 时 间 (Date) + 缓存 时 间 豪 秒 值 (Cache- 
Control: max-age) 。 大 家 可 以 在 如 上 测试 代码 中 对 两 者 进行 单独 测试 ， 
缓存 都 是 可 行 的 。 


2.F5 刷 新 
接着 按 F5 键 刷新 当前 页 面 ， 将 看 到 浏览 器 发 送 如 下 请 求 头 。 


Y Request Headers view source 


Accept text/html,application/xhtml-xml,application/xml;q-8.9,i 
Accept- Ero gzip, deflate, sdch, br 


Cache-Control: max-age-8 
Connection: keep-alive 


Host: localhost:9888 

If-Modified-Since: Tue, 17 Jan 2817 09:26:27 GMT 
Upgrade-Insecure-Requests: 1 

User-Agent: Mozilla/5.8 (Windows NT 6.1; WOW64) AppleMWebKit/537 


此 处 发 送 时 有 一 个 于 -Modified-Since 请 求 尖 ， 其 值 是 上 次 请 求 啊 应 中 的 
Last-Modified， 即 浏览 器 会 用 这 个 时 间 去 服务 器 端 验 证 内 容 是 否 发 生 了 变 
更 。 接 着 收 到 如 下 啊 应 信息 。 


^ MedaUucTs | FTEVIEW TeSpDUISC mMmMmg 
Y General 
Request URL: http: //localhost:9888/cache 


Request Method: GET 
Remote Address: [::1]:96088 
Y Response Headers view source 
Cache-Control: max-age-28 
Date: Tue, 17 Jan 2817 89:26:38 GMT 
Expires: Tue, 17 Jan 2017 89:26:50 GMT 
Last-Modified: Tue, 17 Jan 2017 09:26:27 GMT 


响应 状态 码 为 304， 表 示 服 务 器 端 通知 浏览 器 “你 缓存 的 内 容 没 有 变化 ， 
直接 使 用 缓存 内 容 展示 吧 ”。 


iE: 在 测试 时 ， 要 过 一 段 时 间 就 更 改 一 下 参数 millis ， 以 表示 内 容 修改 
了 ， 要 不 然 会 一 直 看 到 304 啊 应 。 


3.Ctrl+F5 强 制 刷 新 
如 果 你 想 强 制 从 服务 器 端 获 取 最 新 的 内 容 ， 则 可 以 按 “Ctrl+F5” 组 合 键 。 


SS — ———— ee oa ee 
v Request Headers view source | 
Accept: text/html,application/xhtml«xml,ap 
Accept-Encoding: gzip, deflate, sdch, br 
Accept-Language- zh-CH,zh;g-8.8 


Cache-Control: no-cache 
E = J 1, 


eo 


Host: localhost: 9886 

Pragma: no-cache 

Upgrade-Insecure-Requests: 1 
User-Agent: Mozilla/5.8 (Windows NT 6.1; WO 


iu ba aa TE ta KT AN Z1 LIf-Modified-Since, fH f E Cache-Control:no- 
cache 和 Pragma:no-cache， 这 是 为 了 通知 服务 器 端 提 供 一 份 最 新 的 内 容 。 


4.from cache 


当 我 们 按 F5 键 刷新 、 按 “Ctrl+F5” 键 强制 刷新 、 在 地 址 栏 输 入 地 址 刷新 
时 ， 都 会 去 服务 器 端 验 证 内 容 古 否 发 生 了 变更 。 那 什么 情况 才 不 去 服务 
anime ULWE? 有些 朋友 还 会 发 现 有 一 些 “from cache” 的 问题 ， 这 是 什么 情 
况 下 发 生 的 呢 ? 


答案 都 是 ， 从 A 页 面 跳 转 到 A 页 面 或 者 从 A 页 面 跳 转 到 B 页 面 时 。 


1 


d © Developer Tools - http://localhost:9080/cache?millis= 1471349916709 


[x à] Elements Sources Network Timeline Profiles Application Security Audits Console 
| eo © EK Cy View: f= = Preserve log Disable cache Offline No throttling M 
Regex Hide data URLs All XHR JS CSS Img Media Font [£739 WS Manifest 
— — Type Initiator a — Last- 
<> cache?millis=1471349916709 2 document x TUER Aes Te 


大 家 可 以 自行 模拟 从 A 页 面 跳 转 到 A 页 面 。 
之 内 ， 则 直接 从 浏览 器 获取 内 容 ， 


访问 页 面 http://item.jd.conmy11056556.html， 


此 时 ， 如 采 内 容 还 在 缓存 时 间 


而 不 去 服务 器 端 验 证 。 


然后 点 击 面包 悄 中 的 HTTP 权 


威 指南 时 ， 会 跳 转 到 当前 页 面 ， 此 时 看 到 如 下 结果 ， 页 面 及 页 面 异 步 加 


载 的 一 些 js、css、 图 片 都 from cache 了 。 


图 书 计算 机 与 互联 同 > 网 络 与 通信 >| HT 权威 指南 
E anreta HTTP 权 威 指南 
— | Deve 'eloper Tools - http;//itemjd.com/11056556html ~ 
[X Á] | Elements Sources Network e Profiles Application Sec 
= © O e y Viw == 0 
Reg Hide data URL R JS CSS Img Med t Doc WS Manifest Oth 
Nam SUIS Initiator me Last-Mod 
| sensn ie 1^5 Tue 16A 
??ui-base/1.0.0/ui-b m 
Css} R : 
es gene m m TR dms Te 
J ?2jdf/lib/jquery-1.6.4,jsjdf/1.0.0/... 200 " n 
O'REILLY" ganil Bp 360buyimg.com OK cnet 
F3 sem oo "n 2 pt ms Thu M 
j E 引 AAE I n 
bien c EJI gy ECD LADNYOIAAAAAAE LAO) = 1105 ms Sun 20A) 
UR eg] rBEGDIAbNYoIAAAAAAElaOrBI. 2 11056556 html:306 ms | 


还 有 ， 如 通过 浏览 器 历史 记录 进行 前 进 后 退 时 ， 也 会 走 from cache。 本 文 


是 基于 Chrome 52.0.2743.116 m 版 本 测试 ， 


Fo 
5.Age 
一 般 用 于 缓存 代理 层 (如 CDN) 


。 大 家 在 访问 系 东 一 
有 一 个 Age 响 应 头 ， 强 制 刷 新 (Ctrl+F5) 后 会 发 现 其 不 断 变化 。 
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些 页 面 时 ， 会 发 现 
这 表示 此 


内 容 在 缓存 代理 层 从 创建 到 现在 生存 了 多 长 时 间 。 


Y Response Headers 
cache-control: public,max-age-600 
Content-Encoding: gzip 
Content-Type: text/html;charset-utf-8 
Date: Mon, 22 Aug 2016 00:07:00 GMT 


Last-Modified: Sun, 21 Aug 2016 23:59:28 GMT 


Server: jdws 
Vary: Accept-Encoding, Accept-Encoding 


Via: BJ-Y-NX-103(HIT), http/1.1 BJ-UNI-1-2JCS-102 ( [cSsSfU1) 


X-Cache: EXPIRED from LF-CX-F 


6.Vary 


一 般 用 于 缓存 代理 层 (如 CDN) ， 如 响应 头 列 表 ， 如 “Vary:Accept- 
Encoding”、“Vary:User-Agent”， 主 要 用 于 通知 缓存 服务 器 对 于 相同 URL 
有 着 不 同 版 本 的 啊 应 ， 比 如 压缩 版 本 和 非 压 缩 版 本 。 缓 存 服务 名 应 该 根 
据 Vary 头 来 缓存 不 同 版 本 的 内 容 ， 如 指定 啊 应 头 为 “Vary:Accept- 
Encoding”， 则 缓存 代理 层 需 要 根据 <AccepLEncoding” 请 求 头 来 判断 不 同 
版 本 绥 存 内 容 ， 如 “Accept-Encoding:gzip” 请 求 头 版 本 、 无 Accept-Encoding 
请 求 头 版 本 。 


| Y Response Headers view source 
Age: 8 
Connection: keep-alive 
Content-Type: text/html; charset-gbk 
Date: Sun, 18 Dec 2016 10:46:48 GMT 
hh: 1 
ser: 3.88 
Server: jdws 
Transfer-Encoding: chunked 


Vary: Accept-Encoding 


Via: BJ-H-NX-1@9(MISS), http/1.1 BJ-CT-2-JCS-32 ( [cMsSf ]) 


Y Request Headers view source 
Accept text/html, application/xhtml+xm1, application/xm1;q=8.9,image/webp, */*;q=0.8 


Accept-Encoding: gzip, deflate, sdch 


Accept-Language: zh-CN, zh;q=@.8 
Cache-Control: max-age=@ 
Connection: keep-alive 


7.Via 


一 般 用 于 代理 层 (如 CDN) ， 表 示 访 问 到 最 终 内 容 前 经 过 了 哪些 代理 
r Nem 代理 层 是 否 缓存 命中 等 。 通 过 它 可 以 进行 一 些 故障 
诊断 。 


Y Response Headers view source 
Age: 8 
Connection: keep-alive 
Content-Encoding: gzip 
Content-Type: text/html; charset-gbk 
Date: Sun, 18 Dec 2816 18:46:48 GMT 
hh: 1 
ser; 3.88 
Server: jdws 
Transfer- E Seman 


Via: BJ-H-NX-1809(MISS), http/1.1 BJ-CT-2-JC5-32 ( [cMsSf ]) 


10.2.2 ETag 


@RequestMapping ("/cache/etag" ) 

public ResponseEntity<String> cache ( 
// 浏 览 器 验证 文档 内 容 的 实体 I £-None-Match 
@RequestHeader (value = "If-None-Match", required = false) 
String ifNoneMatch) { 


// 当 前 系统 时 间 

long now = System.currentTimeMillis(); 
// 文 档 可 以 在 浏览 器 端 /proxy 上 缓存 多 久 

long maxAge = 10; 


String body = "<a href=''> 点 击 访问 当前 链接 </a>"; 


// 弱 实体 
String etag = "W/\"" + md5(body) + "\""; 


if (StringUtils.equals(ifNoneMatch, etag)) { 
return new ResponseEntity<String>(HttpStatus.NOT MODIFIED); 
} 


DateFormat gmtDateFormat = 
new SimpleDateFormat("EEE, d MMM yyy HH:mm:ss 'GMT'' Lccale.US); 
MultiValueMap<String, String» headers = new HttpHeaders(); 


//ETag http 1.1 支持 

headers.add("ETag", etag); 

// 当 前 系统 时 间 

headers.add("Date", gmtDateFormat.format (new Date (now))); 

// 文 档 生 存 时 间 http 1.1 支持 

headers.add("Cache-Control", "max-age=" + maxAge); 

return new ResponseEntity<String> (body, headers, HttpStatus.OK); 


HB, ETag HH T AA EARS agit TAA Se SEN, If] Catch-Control 
是 用 于 控制 缓存 时 间 的 (浏览 器 、 代 理 层 等 。 此 处 我 们 使 用 了 弱 实体 
WV343sda"”， 弱 实体 ("343sda") 只 要 内 容 语 义 没 变 即 可 。 比 如 ， 内 容 的 
gzip 版 和 非 gzip 版 可 以 使 用 弱 实 体验 证 ， 而 强 实体 指 字 方 必须 完全 一 致 
(gzip 和 非 gzip 情 况 是 不 一 样 的 ) ， 因 此 ， 建 议 首先 选择 使 用 弱 实 体 。 
Nginx 在 生成 Etag 时 使 用 的 算法 是 Last-Modified + Content-Length ° 


ngx sprintf (etag->value.data,"\"%xT-%xO\"", 
r-»headers out.last modified time, 
r-»headers out.content length n) 


到 此 简单 的 基于 文档 修改 时 间 和 过 期 时 间 的 缓存 控制 就 介绍 完了 。 在 内 
容 型 响应 中 ， 我 们 大 多 数 根据 内 容 的 修改 时 间 来 进行 缓存 控制 ，ETag 根 
据 实际 需求 而 定 (比如 图 片 JS/CSS 就 非常 适合 ETag， 而 如 商品 详情 页 使 
用 商品 修改 时 间 ，Last-Modified 处 理 更 简单 一 些 ) 。 另 外 ， 还 可 以 使 用 
hml Mela 标 答 控 制 浏览 器 缓存 ， 但 是 ， 对 代理 层 缓存 无 效 ， 因 此 不 建议 


10.2.3 4 


一 一.1. 请 求 一 一) 
二 一 一 1.2 200+Last-Modified 一 一 一 


—— —2..1.If-Modified-Since———»* 
«———————2.2 304 


1. 服 务 需 端 啊 应 的 Last-Modified 会 在 下 次 请 求 时 ， 将 If-Modified-Since 请 求 
头 融 到 服务 器 端 进行 文档 是 否 修改 的 验证 ， 如 果 没 有 修改 则 返回 304， 浏 
bias A) DLE Ree REA © 


2.Cache-Control:max-age 和 Expires 用 于 决定 浏 蜗 器 端 内 容 缓 在 多 入 ， 即 多 
久 过 期 ， 过 期 后 则 删除 缓存 重新 从 服务 器 端 获 取 最 狐 的 。 男 外 ， 可 以 用 


from cache 场 景 。 


3.HTTP/1.1 规 范 定 义 的 Cache-Control 优 先 级 高 于 HTTP/1.0 规 范 定义 的 
Expires ° 


4. 一 般 情 况 下 Expires= 当 前 系统 时 间 + 缓存 时 间 (Cache-Control:max- 


age) 。 


5.HTTP/1.1 规 范 定 义 ETag 为 “被 请 求 变量 的 实体 值 ”， 可 催 单 理解 为 文档 内 
容 摘要 ，ETag 可 用 来 判断 页 面 内 容 是 否 已 经 被 修改 过 了 。 


Last-Modified 与 ETag 同 时 使 用 时 ， 浏 贤 器 在 验证 时 会 同时 发 送 If- 
Modified-Since 和 If-None-Match。 按照 HTTP/ 1.1 规范 ， 如 果 辣 时 使 用 If- 
Modified-Since 和 If-None-Match， 则 服务 絮 端 必须 两 个 都 验证 通过 后 才能 
返回 304，Nginx 就 是 这 样 做 的 。 因 此 ， 实际 使 用 时 应 该 根据 实际 情况 选 
择 。If-Match 和 If-Unmodified-Since 不 作 介 绍 。 


10.3 HttpClient 客 户 端 缓存 


HttpClient 4.3 版 本 开始 提供 HTTP/1.1 兼 容 的 客户 端 缓存 HTIP/1L.0 缓 存 没 
有 实现 ) ， 可 以 把 该 层 看 成 浏 顺 絮 缓 存 。HttpClient 通 过 职员 链 模 式 来 支 
持 可 插 拔 的 组 件 结构 ， 客 户 端 缓存 就 是 通过 该 模式 实现 的 。 有 了 此 实 
现 ， 直 接 开 箱 即 用 ， 不 需要 额外 写 代码 来 实现 缓存 。 


在 使 用 HttpClient 客 户 剖 缓存 时 ， 需 要 引入 如 下 依赖 。 


<dependency> 
<groupId>org.apache.httpcomponents</groupId> 
<artifactId>httpclient-cache</artifactId> 
<version>4.5.2</version> 

</dependency> 


本 文 使 用 HttpClient 4.5.2 版 本 。 在 使 用 时 ， 要 通过 如 下 配置 创建 HttpClient。 


CacheConfig cacheConfig = CacheConfig.custom() 
.setMaxCacheEntries(1000) // 最 多 缓存 1000 ^H 
.setMaxObjectSize(1 * 1024 * 1024) // 缓 存 对 象 最 大 为 1MB 
.setAsynchronousWorkersCore (5) // 异 步 更 新 缓存 线程 池 最 小 空闲 线程 数 
.SetAsynchronousWorkersMax(10) // 异 步 更 新 缓存 线程 池 最 大 线程 数 
.setRevalidationQueueSize (10000) // 异 步 更 新 线程 池 队 列 大 小 
.build(); 

// 缓 存 存储 

HttpCacheStorage cacheStorage =new BasicHttpCacheStorage (cacheConfig); 

// 创 建 HttpClient 

httpClient = CachingHttpClients.custom() 

.setCacheConfig (cacheConfig) // 缓 存 配置 

.setHttpCacheStorage(cacheStorage) // 缓 存 存储 

.setSchedulingStrategy (new ImmediateSchedulingStrategy 
(cacheConfig)) // 验 证 缓存 时 ， 缓 存 调 度 策略 

.SetConnectionManager (manager) 

.build(); 


如 上 配置 省 略 了 一 些 无 关 配置 ，CachingHttpClients 用 于 创建 市 客户 端 组 
存 的 HttpClient， 其 他 配置 请 参考 HttpClient 连 接 池 配置 章节 。 


CacheConfig 主 要 进行 如 下 几 个 方面 的 配置 。 
. maxCacheEntries: 绥 存 条 目 数 量 ， 当 缓存 的 数量 超 了 会 进行 清除 。 


: maxObjectSize: 每 个 缓存 对 象 的 最 大 大 小 ， 超过 该 大 小 的 内 容 将 不 会 
被 缓存 ， 主 要 目的 是 防止 出 现 缓存 过 大 的 内 容 。 


asynchronousWorkersCore/asynchronousWorkersMax/revalidationQueue 


Size: 异步 更 新 缓存 内 容 线程 池 相关 配置 。 


此 外 ，HttpCacheStorage 用 于 指定 HTTP 响 应 内 容 使 用 什么 存储 器 来 存储 ， 
BasicHttpCacheStorage 表 示 放 在 内 存 中 存储 (使 用 LinkedHashMap 实 现 了 
最 简单 LRU 算 法 ) 。 默 认 还 提供 了 Ehcache 和 Memcached 存 储 实 现 。 其 
BasicHttpCacheStorage 没 有 基于 时 间 的 过 期 策略 ， 建 议 实际 使 用 时 根据 需 
要 选择 如 Ehcache 或 者 自己 扩展 一 个 实现 (比如 ， 扩 展 后 支持 多 级 缓存 : 
玲 内 存 本 地 磁盘 分 布 式 ) 。 


SchedulingStrategy 用 于 配置 当 绥 存 需 要 重新 验证 时 使 用 的 异步 调度 策略 ， 
默认 使 用 ImmediateSchedulingStrategy， 将 使 用 我 们 配置 的 线程 池 参 数 创 
建 线程 池 ， 然 后 异步 进行 重新 验证 请 求 。 


接 下 来 我 们 看 看 使 用 代码 怎么 实现 。 


HttpGet get = new HttpGet ("http://sale.jd.com/act/qXdphQWLoFS.html? 
spm-1.1.0"); 

get.addHeader("User-Agent", "Mozilla/5.0 (Windows NT 6.1; WOW64) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36"); 

HttpCacheContext context = HttpCacheContext.create(); 

CloseableHttpResponse response -getHttpClient().execute(get, context); 

// 缓 存 状态 


CacheResponseStatus cacheResponseStatus = contex. getCacheResponseStatus () ; 


缓存 状态 有 HIT 《响应 命中 ， 返 回 缓存 的 响应 内 容 ， 不 会 发 送 请 求 到 上 游 
服务 器 ) ^ MISS 〈 缓 存 未 命中 ， 响 应 来 和 目 上 游 服 务 器 ) ^ VALIDATED 
(缓存 不 新 鲜 需 要 重新 到 上 游 服务 器 验证 ， 且 验证 后 返回 缓存 中 的 响 
N) 、MODULE_ RESPONSE 《缓存 直接 生成 的 响应 ， 比 如 ， 请 求 


头 “Cache-Control: only-if-cached” 表 示 只 使 用 缓存 内 容 ， 但 是 如 缓存 没 
有 ， 则 生成 一 个 504 啊 应 ， 此 时 缓存 状态 为 MODULE_RESPONSE) 


当 我 们 多 次 调用 如 上 代码 后 会 发 现 ， 第 一 次 访问 时 会 是 MISS， 第 二 次 则 
会 是 HIT。 当 然 ， 前 提 是 上 游 服务 怖 设置 了 缓存 啊 应 头 。 


HttpClient 请 求 流程 如 下 。 


1. 检 查 HITP 请 求 是 否 符合 HITP/1.1 规 范 ， 如 果 不 符合 ， 则 会 进行 修正 
比如， 请 求 头 Cache-Control 同 时 配置 了 max-age 和 no-cache ) 


2. 清 除 该 请 求 中 的 无 效 请 求 头 。 


3. 检 查 该 请 求 是 否 可 以 使 用 缓存 内 容 ， 如 有 果 不 能 则 发 送 请 求 到 上 游 服 务 器 
获取 新 的 内 容 。 


4. 如 果 该 请 求 可 以 使 用 缓存 内 容 作 为 啊 应 ， 则 党 试 读 取 缓存 中 的 缓存 内 
容 。 如 果 读 取 失 败 ， 则 同样 发 送 请 求 到 上 游 服务 器 获取 最 新 的 内 容 。 

5. 如 果 缓 存 的 响应 内 容 可 以 使 用 ， 则 会 构建 一 个 包含 ByteArrayEntity 的 
Po E 否则 ， 会 同上 游 服 务 器 发 出 重新 验证 缓存 内 容 的 
请 5 


6. 如 采 绥 存 的 啊 应 内 容 向 上 游 服务 右 验 证 失败 ， 那 么 会 重新 问 上 游 服 务 器 
发 出 一 次 不 合 缓 存 头 的 请 求 来 获取 最 新 的 内 容 。 


HttpClientr 回 应 流程 如 下 。 
1. 检 查收 到 的 响应 是 否 兼容 HTTP/1.1， 如 果 不 兼 容 ， 则 会 让 其 符合 规范 。 
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3 .如果 响应 数据 太 大 ， 超 出 了 配置 的 大 小 ， 则 直接 返回 响应 不 进行 缓存 。 
10.3.1 ”主流 程 


HttpClient 使 用 了 职责 链 模 式 实 现 ， 使 用 CachingExec 组 件 进行 缓存 相关 操 
作 ， 流 程 代 码 如 下 。 


// 使 请 求 符 合 规范 
requestCompliance.makeRequestCompliant (request); 
// Via 头 ， 请 求 每 经 过 一 层 代 理 将 会 添加 代理 服务 器 标识 ， 
// 通 过 该 头 就 知道 经 过 了 多 少 代理 服务 器 
request.addHeader("Via",via); 
// 清 除 无 效 的 缓存 内 容 
flushEntriesInvalidatedByRequest (context.getTargetHost(), request); 
// 如 果 当 前 不 能 走 缓存 ， 则 直接 访问 上 游 服务 器 
if (!cacheableRequestPolicy.isServableFromCache(request)) { 
log.debug("Request is not servable from cache"); 
return callBackend(route, request, context, execAware); 
} 
// 从 绥 存 获取 内 容 
final HttpCacheEntry entry = satisfyFromCache(target, request); 
if (entry == null) {// 如 果 没 有 命中 ， 则 调用 handleCacheMiss 
return handleCacheMiss(route, request, context, execAware); 
) else {// 如 果 命 中 了 ， 则 调用 handleCacheHit 
return handleCacheHit (route, request, context, execAware, entry); 


10.3.2 ”清除 无 效 缓存 


接 下 来 ， 让 我 们 移 看 一 下 flushEntriesImnvalidatedByRequests 是 怎么 实现 
的 ， 其 会 调用 HttpCacheInvalidator# flushInvalidatedCacheEntries 进 行 清 除 
当前 请 求 相 关 的 无 效 缓存 ; 


// 生 成 缓存 key 
final String theUri = cacheKeyGenerator.getURI (host, req); 
final HttpCacheEntry parent = getEntry (theUri) ;// 获 取 缓存 的 内 容 
// 如 果 请 求 方法 不 是 “GET” 或 “HEAD” 或 者 当前 请 求 是 “GET” 但 是 ， 
/ /缓存 中 的 请 求 方法 是 “HEAD” 
/ /那么 将 需要 清除 无 效 缓存 
if (requestShouldNotBeCached (req) 
|| shouldInvalidateHeadCacheEntry(req, parent)) ( 
if (parent != null) { 
// 失 效 当前 请 求 的 不 同 版 本 CURL 相同 ，Vary 响应 头 不 同 ) 
for (final String variantURI : parentgetVariantMap().values()) ( 
flushEntry (variantURI); 
) 
// 失 效 当前 请 求 
flushEntry (theUri); 
) 
final URL reqURL = getAbsoluteURL (theUri); 
// 如 果 Authority 部 分 一 样 ， 则 失效 “Content-Location” 指 定 URL 的 缓存 
final Header clHdr = req.getFirstHeader ("Content-Location"); 
if (clHdr != null) { 
final String contentLocation = clHdr.getValue(); 
if (!flushAbsoluteUriFromSameHost (reqURL, contentLocation)) { 
flushRelativeUriFromSameHost (reqURL, contentLocation) ; 


) 


final Header lHdr = req.getFirstHeader ("Location"); 
if (lHdr !- null) {//KRM "Location" HE URI 的 缓存 
flushAbsoluteUriFromSameHost(reqURL, lHdr.getValue()); 


此 处 使 用 CacheKeyGenerator 生 成 缓存 key，key 格 式 为 protocol + hostname 
port + path  "?" + query ° 


10.3.3 ”查找 缓存 


接 下 来 我 们 看 一 下 CacheableRequestPolicy #isServableFromCache 77 2 , 
其 用 于 判断 当前 是 否 可 以 使 用 缓存 。 


public boolean isServableFromCache(final HttpRequest request) ( 
final String method = request.getRequestLine().getMethod(); 
final ProtocolVersion pv - 


request.getRequestLine(). getProtocolVersion(); 
// 如 果 请 求 不 是 HTTP/1.1， 则 不 能 走 缓存 
if (HttpVersion.HTTP 1 l.compareToVersion(pv) !- 0) ( 


return false; 
) 
// 如 果 请 求 方法 不 是 “GET” 或 者 “HEAD” 方 法 ， 不 能 走 缓存 
if (!(method.equals(HeaderConstants.GET METHOD) || method 
.equals (HeaderConstants.HEAD METHOD))) { 
return false; 
) 
// 如 果 请 求 头 有 “Pragma”， 则 不 能 走 缓存 
if (request.getHeaders (HeaderConstants.PRAGMA).length > 0) { 
return false; 
} 
// 如 果 请 求 头 “Cache-Contro1” 为 “no-store” 或 者 “no-cache” 则 不 能 走 缓存 
final Header[] cacheControlHeaders = 
request.getHeaders (HeaderConstants.CACHE CONTROL); 
for (final Header cacheControl : cacheControlHeaders) { 
for (final HeaderElement cacheControlElement : 
cacheControl.getElements()) ( 
if ("no-store" 
.equalsIgnoreCase (cacheControlElement.getName())) { 
return false; 
) 
if ("no-cache" 
.equalsIgnoreCase (cacheControlElement.getName())) { 
return false; 


) 


return true; 


此 处 只 是 请 求 不 能 使 用 缓存 ， 并 不 会 影响 请 求 啊 应 的 缓存 。 态 外， 
HttpClient 目 前 只 对 HTTP/1.1 提 供 客户 端 缓存 文 持 。 


satisfyFromCache 方 法 委托 BasicHttpCache#getCacheEntry 方 法 从 缓存 中 获 
取 缓 存 内 容 。 


// 首 先 根 据 URL 缓存 key 获取 缓存 内 容 
final HttpCacheEntry root = storage.getEntry (uriExtractor.getURI (host, 


request)); 


if (root == null) {// 如 果 没有 缓存 ， 则 直接 返回 


return null; 


} 
if (!root.hasVariants()) {// 如 果 缓 存 不 存在 ， 则 是 Vary 版 本 的 变 体 


return root; 


) 
// 获 取 vary 版 本 的 URL 缓存 key 


final String variantCacheKey = root.getVariantMap().get (uriExtractor. 


getVariantKey(request, root)); 
if (variantCacheKey == null) { 
return null; 


) 
// 获 取 并 使 用 Vary 版 本 的 URL 缓存 


return storage.getEntry(variantCacheKey) ; 


之 前 部 分 已 经 解释 了 Vary， 此 处 也 得 到 了 验证 。 


10.3.4 ”缓存 未 命中 


如 果 客 户 端 缓 存 没 有 命中 ， 则 调用 handleCacheMiss 方 法 执行 未 命中 膛 
ER o 


// 如 果 有 请 求 头 “cache-Control: only-if-cached”， 则 表示 请 求 只 从 缓存 中 获取 ， 
// 未 命中 情况 返回 504 状态 码 
if (!mayCallBackend(request)) { 
return Proxies.enhanceResponse( 
new BasicHttpResponse( 
HttpVersion.HTTP 1 1, 
HttpStatus.SC GATEWAY TIMEOUT, 
"Gateway Timeout")); 
) 
// 获 取 带 Etag 版 本 的 Vary 版 本 URL, WRA, 则 调用 negotiateResponseFromVariants 
final Map<String, Variant» variants = getExistingCacheVariants (target, 
request); 
if (variants != null && !variants.isEmpty()) { 
return negotiateResponseFromVariants (route, request, context, 
execAware, variants); 
) 
// 和 否则 调用 callBackend 回 源 到 上 游 服务 器 


return callBackend(route, request, context, execAware); 


10.3.5 ”缓存 命中 


接 下 来 ， 我 们 移 看 一 下 客户 端 缓存 命中 后 调用 handleCacheHit 方 法 执行 的 
命中 逻辑 。 


// 用 于 判断 缓存 的 啊 应 是 否 可 以 直接 返回 给 客户 
if (suitabilityChecker.canCachedResponseBeUsed(target, request, entry, 


now)) ( 
// 命 中 后 生成 缓存 响应 
out = generateCachedResponse (request, context, entry, now); 
// 缓 存 不 新 鲜 需 要 验证 ， 如 果 请 求 头 有 “Cache-Control: only-if-cached”, 
// 则 表示 强制 从 缓存 中 获取 ， 因 此 返回 504 响应 
} else if (!mayCallBackend(request)) { 
out = generateGatewayTimeout (context); 
// 缓 存 不 新 鲜 需 要 验证 ， 如 果 缓 存 响 应 的 状态 码 不 是 304， 
// 或 者 条 件 请 求 有 请 求 头 “"If-None-Match” 或 “If-Modified-Sincey 
// 则 需要 请 求 上 游 服 务 器 进行 重新 验证 
} else if (!(entry.getStatusCode() == HttpStatus.SC NOT MODIFIED 
&& !suitabilityChecker.isConditional(request))) { 
return revalidateCacheEntry(route, request, context, execAware, entry, 
now); 
) else { 
// 其 他 情况 ， 直 接 回 源 上 游 服务 器 获取 最 新 内 容 


return callBackend(route, request, context, execAware); 


Hot, @ CachedResponseSuitabilityChecker#canCachedResponseBeUsed Jj 
法 ， 其 用 于 判断 是 否 可 以 使 用 缓存 的 内 容 作为 啊 应 。 


// 如 果 绥 存 的 内 容 不 是 新 鲜 的 ， 则 不 能 使 用 缓存 
if (!isFreshEnough(entry, request, now)) { 
return false; 
} 
// 如 果 请 求 方法 是 “GET” 且 缓存 中 的 响应 头 “Content-Length” 
// 与 缓存 Body 体 实际 长 度 不 一 样 ， 则 可 能 内 容 不 完整 ， 不 能 使 用 缓存 
if (isGet(request) 
&& !validityStrategy 
.contentLengthHeaderMatchesActualLength(entry)) { 
return false; 
} 
// 如 果 请 求 头 有 If-Range. If-Match. If-Unmodified-Since, 
// 则 HttpClient 不 支持 ， 不 能 使 用 缓存 
if (hasUnsupportedConditionalHeaders (request)) { 
return false; 
} 
/ /如果 缓存 响应 状态 码 为 304， 但 不 是 条 件 请 求 
// (没有 请 求 头 If-None-Match/ If-Modifieqdq-Since)， 则 不 能 使 用 缓存 
if (!isConditional (request) 
&& entry.getStatusCode() == HttpStatus. SC NOT MODIFIED) 
return false; 


/ /如果 是 条 件 请 求 (请 求 时 ， 业 务 代码 自己 设置 了 If-None-Match/ If-Modified-Since, 
// 不 建议 这 样 ， 除 非 有 具体 理由 ) ， 但 是 条 件 请 求 与 缓存 中 的 响应 头 (Etag/Last-Modified) 
// 不 匹配 〈 如 果 两 个 都 存在 ， 则 两 个 要 都 匹配 才 可 以 )， 则 不 能 使 用 缓存 
if (isConditional (request) 
&& lallConditionalsMatch(request, entry, now)) { 

return false; 
} 
// 如 果 缓 存 内 容 的 请 求 方法 或 内 容 体 为 空 ， 或 者 是 一 个 204 响应 ， 则 不 能 使 用 缓存 
if (hasUnsupportedCacheEntryForGet(request, entry)) { 

return false; 
} 


for (final Header ccHdr : 
request.getHeaders (HeaderConstants. CACHE CONTROL)) (| 


for (final HeaderElement elt : ccHdr.getElements()) { 
// 如 果 请 求 头 有 “Cache-Control:no-cache”， 则 不 能 使 用 缓存 ， 需 要 回 源 验 证 
if (HeaderConstants.CACHE CONTROL NO CACHE 
.equals(elt.getName())) { 
return false; 


) 
// 如 果 请 求 头 有 “Cache-Control:no-store” ， 则 不 能 使 用 缓存 
if (HeaderConstants.CACHE CONTROL NO STORE 
.equals(elt.getName())) { 
return false; 
} 
// 如 果 请 求 头 有 “cache-Control:max-age=time”， 且 当前 Age > max-age, 
// 则 不 能 使 用 缓存 
if (HeaderConstants.CACHE CONTROL MAX AGE 
.equals(elt.getName())) { 
final int maxage - Integer.parseInt(elt.getValue()); 
if (validityStrategy.getCurrentAgeSecs (entry, now) > maxage) { 
return false; 
) 
) 
/ L'A RA *Cache-Control:max-stale-time", 
// 且 保鲜 时 间 > max-stale( 最 大 陈旧 时 间 )， 这 说 明 内 容 陈 旧 了 
//〔 最 大 陈旧 时 间 要 比 保鲜 时 间 更 长 才 对 )， 则 不 能 使 用 缓存 
if (HeaderConstants.CACHE CONTROL MAX STALE 
.equals(elt.getName())) { 
final int maxstale = Integer.parseInt(elt.getValue()); 
if (validityStrategy.getFreshnessLifetimeSecs (entry) 
> maxstale) { 


return false; 


/ /如果 请 求 小 有 “Cache-Control:min-fresh=time”， 
// 且 (保鲜 期 -当前 Age) < min-fresh (最 小 保鲜 时 间 )， 
// 这 说 明 内 容 不 新 鲜 ， 则 不 能 使 用 缓存 
if (HeaderConstants.CACHE CONTROL MIN FRESH 
.equals(elt.getName())) { 
final long minfresh = Long.parseLong(elt.getValue()); 
if (minfresh < OL) { 
return false; 
} 
final long age - 
validityStrategy.getCurrentAgeSecs (entry, now); 
final long freshness - 
validityStrategy.getFreshnessLifetimeSecs (entry); 
if (freshness - age < minfresh) { 
return false; 


) 


) 
) 


return true; 
. 请 求 时 间 :， 表 示 HttpClient 创 建 请 求 的 时 间 。 
. 响应 时 间 :， 表示 HttpClient 接 收 到 响应 的 时 间 。 
.响应 头 Date: ”表示 上 游 服 务 器 创建 内 容 的 时 间 ， 跟 随 响 应 返回 给 客户 


端 。 

` 接收 时 Age: 如 果 有 代理 缓存 服务 器 ， 则 响应 头 会 有 Age， 表 示 内 容 在 
缓存 服务 器 已 经 存在 了 多 和 久 。 还 可 以 通过 〈 响 应 时 间 - 响 应 头 Date) 来 计 
算 初 始 时 间 ， 这 两 个 时 间 取 最 大 的 一 个 。 


当前 Age: 内 容 的 当前 生存 期 ， 即 内 容 已 经 存在 多 久 了 ， 等 于 “接收 时 
Age”+“ 响 应 延迟 ” (响应 时 间 - 请 求 时 间 ) +* 当 前 系统 时 间 -响应 时 间 ”。 


- 保鲜 时 间 : 即 内 容 允 许 缓 存 的 最 大 时 间 ， 为 “Cache-Control:max- 


age”、\“Cache-Control:s-maxage” 或 “Expires-Date”。 


下 面 是 isFreshEnough 方 法 的 实现 。 


// 如 果 当 前 Age< 保 鲜 时 间 ， 表 示 绥 存 啊 应 是 新 鲜 的 
if (getCurrentAgeSecs(entry, now) < getFreshnessLifetimeSecs(entry)) { 
return true; 
} 
// 如 果 使 用 启发 式 缓存 〈 默 认 没 开 启 )， 且 判断 是 新 鲜 的 ， 则 返回 缓存 内 容 给 客户 
if (useHeuristicCaching && 
validityStrategy.isResponseHeuristicallyFresh( 
entry, now,heuristicCoefficient, heuristicDefaultLifetime)) { 


return true; 
) 
/ /如果 缓存 响应 有 响应 头 “Cache-Control:must-revalidate”, 则 内 容 需 要 重新 验证 ， 
// 即 不 新 鲜 
if (validityStrategy.mustRevalidate(entry)) { 
return false; 
) 
// 如 果 开 启 共享 缓存 (只 缓存 public I, private 不 缓存 ) 
// 如 果 缓 存 响应 有 响应 头 “Cache-Control: proxyrevalidate” 或 者 “Cache-Control: 
//s-maxage", 则 认为 内 容 不 新 鲜 
if (sharedCache) { 
if(validityStrategy.proxyRevalidate(entry) || 
validityStrategy.hasCacheControlDirective(entry, "s-maxage")) { 
return false; 
) 
) 
// 当 前 Age- 保 鲜 时 间 为 内 容 已 陈旧 时 间 ， 即 不 新 鲜 多 久 了 
// 如 果 请 求 中 的 最 大 陈旧 时 间 > 已 陈 旧时 间 ， 则 说 明 允 许 返 回 陈旧 不 新 鲜 的 内 容 
final long maxstale = getMaxStale (request); 
if (maxstale == -1) {//maxstale 等 于 -1 表示 没有 设置 陈旧 时 间 ， 认 为 内 容 陈 旧 不 新 鲜 了 
return false; 
} 
long stalenessSecs = 0L; 
final long age = getCurrentAgeSecs (entry, now); 
final long freshness = getFreshnessLifetimeSecs (entry); 
if (age <= freshness) { 


stalenessSecs = 0L; 
} else { 
stalenessSecs = (age - freshness) ; 


} 


return (maxstale > stalenessSecs); 


10.3.6 ”缓存 内 容 陈旧 需 重 新 验证 


接 来 下 ， 看 一 下 CachingExecftrevalidateCacheEntry 实 现 。 


// 如 果 创 建 了 异步 验证 器 〈 当 配置 了 asynchronousWorkersMax>0 时 会 创建 ) 
// 如 果 人 允许 陈旧 的 响应 ， 且 前 往 上 游 服 务 器 验证 时 允许 返回 陈旧 的 啊 应 ， 则 使 用 异步 后 台 验 证 
if (asynchRevalidator != null 

&& !staleResponseNotAllowed(request, entry, now) 

&& validityPolicy.mayReturnStaleWhileRevalidating(entry, now)) { 


final CloseableHttpResponse resp - 
generateCachedResponse(request, context, entry, now); 


asynchRevalidator.revalidateCacheEntry( 


this, route, request, context, execAware, entry); 
return resp; 
} 
// fW), H7 Sur 
return revalidateCacheEntry(route, request, context, execAware, entry); 


CachingExec#staleResponseNotAllowed 表 示 哪 些 情况 必须 前 往 上 游 服 务 器 
验证 ， 不 能 返回 陈旧 的 内 容 。 


: UFR EAE AY bs] by *-“Cache-Control:must-revalidate ”。 


MRA SHER, EAN DY A WU “Cache-Control: proxy- 


revalidate ” ° 


. 或 者 ， 如 果 缓 存 的 啊 应 有 了 啊 应 头 “Cache-Control:max-stale ”， 当 内 容 陈 
旧时 (当前 Age- 保 鲜 期 )> 最 大 陈旧 时 间 。 


- 如 果 有 “Cache-Control:min-fresh” 或 者 “Cache-Control:max-age” 时 (执行 
到 此 处 说 明 内 容 已 经 不 新 鲜 了 ， 不 满足 新 鲜 条 件 ) o 


CacheValidityPolicy#mayReturnStaleWhileRevalidating 实 现 。 


如 果 缓 存 啊 应 的 啊 应 头 有 “Cache-Control: stale-while-revalidate-time ” , 
此 time 指 定 在 验证 期 间 允 许 返 回 陈 旧 的 响应 ( 即 可 以 异步 后 台 验 证 ) ， 且 
已 陈旧 时 间 <=time， 则 可 以 异步 验证 ， 并 返回 陈旧 的 内 容 。 


接 下 来 ， 看 一 下 CachingExec#revalidateCacheEntry 如 何 进 行 验证 《省略 了 
一 些 非 关 键 代码 ) o 


// 构 建 条 件 请 求 
final HttpRequestWrapper conditionalRequest -conditionalRequestBuilder. 
buildConditionalRequest(request, cacheEntry); 


// 请 求 时 间 
Date requestDate = getCurrentDate(); 
// 执 行 条 件 请 求 
CloseableHttpResponse backendResponse = 

backend.execute( 

route, conditionalRequest, context, execAware); 

// 啊 应 时 间 
Date responseDate = getCurrentDate(); 


// 如 果 响 应 太 旧 《响应 时 间 早 于 缓存 的 响应 头 Date 时 间 )， 则 重新 发 出 一 次 非 条 件 查询 重新 获取 
if (revalidationResponseIsTooOld(backendResponse, cacheEntry)) { 
backendResponse.close(); 


final HttpRequestWrapper unconditional = conditionalRequestBuilder 
.buildUnconditionalRequest (request, cacheEntry); 
requestDate - getCurrentDate(); 
backendResponse - 
backend.execute(route, unconditional, context, execAware); 
responseDate - getCurrentDate(); 


final int statusCode - backendResponse.getStatusLine().getStatusCode(); 
if (statusCode -- HttpStatus.SC NOT MODIFIED 
|| statusCode -- HttpStatus.SC OK) ( 
// 缓 存 状 态 为 VALIDRATED 
setResponseStatus (context, CacheResponseStatus. VALIDATED) ; 


if (statusCode == HttpStatus.SC_NOT_MODIFIED) { 
// 如 果 响 应 返回 304， 则 说 明 内 容 没 有 变化 
final HttpCacheEntry updatedEntry = responseCache.updateCacheEntry( 
context.getTargetHost(), request, cacheEntry, 
backendResponse, requestDate, responseDate); 
// 如 果 当 前 请 求 是 条 件 查询 ， 且 “Etag/Last-Modified” 都 匹配 ， 则 生成 304 响应 
if (suitabilityChecker.isConditional(request) 
&& suitabilityChecker.allConditionalsMatch( 
request, updatedEntry,new Date())) { 
return responseGenerator 
.generateNotModifiedResponse (updatedEntry); 
) 
// 正 常 响应 
return responseGenerator.generateResponse(request, updatedEntry); 


// 处 理 后 端 响应 ， 比 如 缓存 响应 
return handleBackendResponse (conditionalRequest, context, requestDate, 
responseDate, backendResponse); 


ConditionalRequestBuilder#buildConditionalRequest 用 于 构建 条 件 请 求 。 

// 复 制 请 求 

final HttpRequestWrapper newRequest - 
HttpRequestWrapper.wrap(request. getOriginal()); 

// 复 制 请 求 头 

newRequest.setHeaders (request.getAllHeaders()); 

/7/ 如 果 缓 存 啊 应 中 有 Etag， 则 将 Etag 设置 到 请 求 头 I£-None-Match 

final Header eTag = cacheEntry.getFirstHeader (HeaderConstants.ETAG) ; 

if (eTag != null) { 


newRequest.setHeader( 
HeaderConstants.IF NONE MATCH, eTag.getValue()); 


} 
// 如 果 缓 存 响应 中 有 Last-Modified, 
// 则 将 Last-Modified 设置 到 请 求 头 If£-Modified-Since 
final Header lastModified = 
cacheEntry.getFirstHeader (HeaderConstants.LAST MODIFIED); 
if (lastModified != null) { 


newRequest.setHeader( 
HeaderConstants.IF MODIFIED SINCE, lastModified.getValue()); 


} 
boolean mustRevalidate = false; 


for(final Header h : 
cacheEntry.getHeaders (HeaderConstants.CACHE CONTROL)) { 


for(final HeaderElement elt : h.getElements()) ( 
if (HeaderConstants.CACHE CONTROL MUST REVALIDATE 
. equalsIgnoreCase (elt.getName()) 


|| HeaderConstants.CACHE CONTROL PROXY REVALIDATE 

. equalsIgnoreCase(elt.getName())) { 
mustRevalidate - true; 
break; 


} 
// 如 果 必 须 强制 验证 (类 似 于 浏览 器 按 了 F5 BED, 则 设置 请 求 头 “cache-Control:max-age=0?” 


if (mustRevalidate) { 


newRequest.addHeader( 
HeaderConstants.CACHE CONTROL, 


HeaderConstants.CACHE CONTROL MAX AGE + "z0"); 
) 


return newRequest; 


10.3.7 缓存 内 容 无 效 需 重新 执行 请 求 


接 下 来 ， 看 一 下 CachingExec#callBackend 实 现 。 


// 执 行 请 求 
final CloseableHttpResponse backendResponse = 

backend.execute(route, request, context, execAware); 
// 添 加 Via 3k 
backendResponse.addHeader("Via", generateViaHeader (backendResponse)); 
// 处 理 后 端 响应 ， 如 缓存 响应 


return handleBackendResponse(request, context, requestDate, 


10.3.8 ”缓存 响应 


最 后 我 们 来 看 一 下 CachingExec#handleBackendResponse 人 逻辑。 
/ /判断 响应 是 否 可 以 缓存 


final boolean cacheable = responseCachingPolicy.isResponseCacheable ( 
request, backendResponse); 


getCurrentDate(), backendResponse); 


// 清 除 过 期 的 缓存 条 目 
responseCache.flushInvalidatedCacheEntriesFor( 
target, request, backendResponse); 
// 如 果 可 以 缓存 ， 并 且 缓 存 中 没有 更 新 的 缓冲 条 目 《〈 比 如 被 别 的 线程 更 新 了 )， 则 缓存 响应 
if (cacheable && 
lalreadyHaveNewerCacheEntry(target, request, backendResponse)) { 

// 如 果 响 应 状态 码 为 304， 如 果 有 请 求 头 1£-Modified-Since, 

// 则 将 其 添加 到 响应 头 Last-Modified 
storeRequestIfModifiedSinceFor304Response (request, backendResponse); 
return responseCache.cacheAndReturnResponse(target, request, 

backendResponse, requestDate, responseDate); 
} 
// 如 果 不 缓存 ， 则 清除 缓存 条 目 
if (!cacheable) { 
responseCache.flushCacheEntriesFor(target, request); 


ResponseCachingPolicy#isResponseCacheable 用 于 判断 什么 情况 下 可 以 缓存 。 
- 如 果 请 求 协议 版 本 不 是 HTTP/1.1， 则 不 能 缓存 。 


- 如 果 “Cache-Control:no-store” 则 不 能 缓存 (no-cache 是 可 以 缓存 的 ， 但 是 
每 次 需要 验证 ) ° 


如果 URL 中 有 ”“?”， 且 CacheConfig 配 置 了 neverCacheHTTP10Responses 
WithQuery=true 〈 表 示 从 不 缓存 带 参数 的 HITP/1.0 响 应 ) ， 如 果 响 应 头 
Via 有 “HTTP/1.0” 或 “1.0”"， 则 表示 中 间 代 理 层 有 HTTP/1.0 的 版 本 ， 不 能 绥 
存 。 


-如 采 URL 中 有 ”“?”， 且 没有 缓存 头 “ 下 xpires” 或 “Cache-Control” 为 max- 
age、Ss-maxage、must-revalidate、Pproxy-revalidate、public， 则 不 能 缓存 。 


EN dUN 表示 内 容 已 陈旧 ， 则 不 能 组 
子 O 


WAF TAS BF (sharedCache) ， 如 果 有 请 求 头 “Authorization”， 
(H zi] M “Cache-Control” Yx A s-maxage ^ must-revalidategV publich}, ll] 
不 能 缓存 。 


. 如 果 请 求 方法 不 是 GET、HEAD， 则 不 能 缓存 。 
如果 响应 状态 码 不 为 200、203、300、301、410， 则 不 能 缓存 。 
: 如 果 Content-Length>maxObjectSize， 则 不 能 缓存 。 

. 如 果 有 多 个 Age、Expires 头 ， 则 不 能 缓存 。 

:如果 Date 头 不 为 1 个 ， 或 者 Date 无 法 解析 ， 则 不 能 缓存 。 

如果 Vary 征 *， 则 不 能 缓存 。 


- 如 果 Cache-Control 为 no-store、no-cache、 或 者 private， 但 开启 了 共享 组 
存 ， 则 不 缓存 。 


在 默认 情况 下 ，HttpClient CacheConfig 参 数 (isSharedCache=true) 表示 只 
缓存 公有 缓存 (public) ， 不 会 缓存 带 有 授权 头 “Authorization”《 除 非 明确 上 
定 为 public) 或 private 缓 存 ， 可 以 设置 isSharedCache=false 来 关闭 共享 组 
存 o 


Heuristic Cache ， 即 启发 式 缓存 ， 即 使 服务 器 没有 明确 设置 缓存 控制 头 
时 ， 它 也 会 缓存 一 定数 目的 响应 ， 默 认 是 关闭 的 。 如 果 需 要 ， 则 可 以 配 
置 CacheConfig 的 heuristicCachingEnabled 、 heuristicCoefficient 、 
heuristicDefaultLifetime 相 关 参 数 开启 。 


到 此 我 们 介绍 完了 HttpClient 缓 存 的 主要 内 容 ， 其 中 忽略 了 一 些 不 影响 主 
流程 的 细节 ， 如 果 想 要 彻底 理解 ， 则 建议 深入 阅读 源码 。 


10.3.9 ”缓存 头 总 结 
根据 如 上 的 源码 分 析 ， 我 们 再 总 结 一 下 Cache-Control 。 


.public 响应 头 ， 可 共享 缓存 (客户 端 和 代理 服务 器 都 可 以 缓存 ) ， 响 
应 可 以 被 缓存 。 


private: MAA, WARE (客户 端 可 以 缓存 ， 代 理 服务 器 不 能 组 
TE) ， 比 如 用 户 私 有 内 容 ， 不 能 共享 。 


. no-cache: 请 求 头 使 用 时 表示 需要 回 源 验证 ， 啊 应 头 使 用 时 表示 允许 绥 
oi E 但 是 ， 使 用 时 必须 回 源 验证 ， 所 以 此 处 叫 no-cache 并 不 是 
很 好 。 

-no-store: 请 求 和 响应 禁止 缓存 。 

-max-age: ” 绥 存 的 保鲜 期 和 Expires 类 似 ， 根 据 该 值 校 验 缓存 是 否 新 鲜 。 


| S-maxage:: 与 max-age 的 区 别 是 其 仅 用 于 共享 缓存 〈 如 缓存 代理 服务 
WR) ， 当 客户 端 绥 存 不 新 鲜 时 遇 到 此 头 要 重新 验证 。 


-max-stale: 绥 存 的 最 大 陈旧 时 间 ， 如 果 绥 存 不 新 鲜 但 还 在 该 最 大 陈旧 时 
间 内 ， 则 可 以 返回 陈旧 的 内 容 。 


- min-fresh: ”缓存 的 最 小 新 鲜 期 ， 请 求 时 使 用 (保鲜 期 -当前 Age) < 
min-fresh 判 断 内 容 是 否 新 鲜 。 


-must-revalidate: 当 缓 存 过 了 新 鲜 期 后 ， 必 须 回 源 重 新 验证 。 与 no- 
om 但 是 更 严格 ， 不 能 使 用 后 台 重 新 验证 ， 而 no-cache 人 允许 后 台 重 
新 验证 。 


por s 与 mustrevalidate 类 似 ， 但 是 ， 只 对 缓存 代理 服务 器 
有 效 ， 客 户 端 遇 到 此 头 需 要 回 源 重 新 验证 。 


- stale-while-revalidate: ”请求 时 ， 表 示 在 指定 的 时 间 内 可 以 先 返回 陈旧 
的 内 容 ， 后 台 进 行 重 新 验证 (如 异步 验证 ) 。 


-stale-if-error: 请 求 时 ， 表 示 在 指定 的 时 间 内 ， 当 重新 验证 请 求 响应 状 
态 码 为 500、502、503、504 时 ， 可 以 使 用 陈旧 内 容 。 


-only-if-cached: 请求 时 ， 使 用 该 头 表 示 只 从 缓存 获取 响应 ， 如 果 没 有 ， 
则 504 Gateway Timeout ° 


10.4 Nginx HTTP 缓 存 设 置 


Nginx fe f T expires ^ etag ` if-modified-since #4 $ 36 SK EW 9d, as Zt T PE 
制 。 


10.4.1 expires 


E ee ae 那么 可 以 使 用 expires 进 行 缓存 
73| o 


location /img { 
alias /export/img/; 
expires 1d; 


) 


当 我 们 访问 静态 资源 ， 如 http://192.168.61.129/img/1.jpg 时 ， 将 得 到 类 似 如 
下 的 响应 头 。 


Request URL: http://192.168.61.129/img/1.jpg 

Request Method: GET 

Status Code: @ 200 OK 

Remote Address: 192.168.61.129:80 
Y Response Headers 
Accept-Ranges: bytes 
Cache-Control: max-age-86400 


Connection: keep-alive 
Content-Length: 109589 

Content-Type: image/jpeg 

Date: Tue, 16 Aug 2016 13:05:50 GMT 


ETag: "57ad8c74-1ac15" 
Expires: Wed, 17 Aug 2016 13:05:50 GMT 


Last-Modified: Fri, 12 Aug 2016 08:44:36 GMT 
Server: openresty/1.9.7.4 


对 于 静态 资源 会 和 目 动 添加 ETag ， 可 以 通过 配置 etag off 指 令 禁 止 生 成 
ETag。 如 果 是 静态 文件 ， 那 么 Last-Modified 值 为 文件 的 最 后 修改 时 间 。 
Expires 是 根据 当前 服务 器 系统 时 间 算出 来 的 。 如 下 是 Nginx expires 配 置 的 
计算 逻辑 (实际 计算 逻辑 要 更 多 ， 请 参考 官方 文档 ) 。 


if (expires == NGX HTTP EXPIRES ACCESS ||r->headers out.last modified 
time == -1) { 
max age - expires time; 
expires time += now; 


} 


10.4.2 if-modified-since 


H 45S FAP 8 XE Nginx A fart Hit 25 88 Ym HY Last-Modified fU 2] 90, 28 Sita AY if- 
modifiedsince 时 间 进 行 比 较 ， 默 认 的 “if modified since exact" #275 tH ff DE 
配 ， 也 可 以 使 用 “if modified_since _before” 和 表示 只 要 文件 的 最 后 修改 时 间 
早 于 或 等 于 浏览 器 端的 if-modified-since 上 时 间 ， 就 返回 304。 


10.4.3 nginx proxy_pass 


使 用 Nginx 作 为 反问 代理 时 ， 请 求 会 先进 入 Nginx， 然后 Nginx 将 请 求 转 发 
给 后 端 应 用 ， 如 下 网 所 示 。 


1.1 请 求 2.2 response 
Nginx 
1.2 proxy pass 2.1 response 
Java Web 应 用 


首先 配置 upstream ° 


upstream backend tomcat { 
server 192.168.61.1:9080 max fails-10 fail timeout-10s weight-5; 


) 


接着 配置 location 


location = /cache { 
proxy pass http://backend tomcat/cache$is args$args; 
) 


fe 下来， 我 们 可 以 通过 如 http://192.168.61.129/cache? 
millis=1471349916709 访 问 Nginx，Nginx 会 将 请 求 转发 给 后 端 Java 应 用 。 
也 就 是 说 Nginx 只 是 做 了 相关 的 转发 负载 均衡 ， 并 没有 对 请 求 和 响应 
做 什么 处 理 。 


假设 需要 对 后 端 运 回 的 过 期 时 间 进 行 调整 ， 可 以 添加 Expires 指 令 到 


location ° 


location = /cache { 
proxy pass http://backend tomcat/cache$is args$args; 
expires 5s; 


) 


然后 再 请 求 相 关 的 URL， 将 得 到 如 下 响应 。 


Y E Headers ew source 
Connection: keep-alive 
Content-Length: 39 
Content-Type: text/html;charset-UTF-8 
L— Wed, 17 Pg 2016 89:38:45 GMT 

hi n g 


d E 6 89:39:58 GMT 
Last- Modified: Tue, 16 Aug 2016 20:18:36 GMT 
Server: openresty/1.9.7.4 


过 期 时 间 相 关 的 响应 头 被 Expires 指 令 更 改 了 ， 但 是 last-modified 是 没有 变 
的 。 


即使 我 们 更 改 了 缓存 过 期 头 ， 但 Nginx 自 己 没 有 对 这 些 内 容 做 代理 层 缓 
存 ， 每 次 请 求 还 是 要 到 后 端 验 证 的 。 假 设 在 过 期 时 间 内 ， 这 些 验 证 在 
Nginx 这 一 层 进行 就 可 以 了 ， 不 需要 到 后 端 验 证 ， 这 样 可 以 减少 后 端 很 大 
的 压力 。 具 体 整体 流程 如 下 。 


1. 浏 览 器 发 起 请 求 ， 首 先 到 Nginx，Nginx 根 据 URL 在 Nginx 本 地 查找 是 否 
有 代理 层 本 地 缓存 。 


2.Nginx 没 有 找到 本 地 缓存 ， 则 访问 后 端 获取 最 新 的 文 和 并 放 入 Nginx 本 
地 缓存 ， 返 回 200 状 态 码 和 最 新 的 文档 给 浏览 需 


3.Nginx 找 到 本 地 缓存 ， 首 先 验证 文档 是 否 过 期 (Cache-Control:max- 
age-5) 。 如 果 过 期 ， 则 访问 后 端 获 取 最 新 的 文 要 ， 并 放 入 Nginx 本 地 组 
存 ， 返 回 200 状 态 码 和 最 新 的 文档 给 浏览 器 ; 如 果 文 档 没有 过 期 Bit 
modified-since 与 缓存 文档 的 lastmodified 匹 配 ， 则 返回 304 状 态 码 给 浏览 
器 。 

内 容 不 需要 访问 后 端 ， 即 不 需要 后 端 动态 计算 /次 染 等 ， 直 接 Nginx 代 理 层 
就 把 内 容 返 回 ， 速 度 更 快 内 容 越 接近 于 用 户 速 度 越 快 。 像 Apache 
Traffic Server ` Squid ` Varnish ` Nginx NARA] UH RFI NRR ° 
还 有 CDN 技 术 束 是 用 来 加 速 用 户 访问 的 。 


广州 CDN 节 点 北京 CDN 节 点 上 海 CDN 节 点 
中 央 nginx 集 群 
后 端 应 用 集群 


用 户 首 先 访问 全 国 各 地 的 CDN 节 点 (使 用 如 ATS、Squid 实 现 ) ， 如 果 
CDN 没 命中 ， 则 会 回 源 到 中 央 Nginx 集 群 ， 该 集群 做 二 级 缓存 ， 如 果 没 有 
命中 缓存 (该 集群 的 缓存 不 是 必须 的 ， 要 根据 实际 命中 情况 等 决定 ) ， 
则 最 后 回 源 到 后 端 应 用 集群 。 


像 我 们 商品 详情 页 的 一 些 服务 就 大 量 使 用 了 Nginx 绥 存 减 少 回 源 到 后 端的 


请 求 量 ， 从 而 提升 访问 速度 。 可 以 参考 "第 11 章 多 级 缓存 "、“ 第 16 章 构建 
需求 响应 式 亿 级 商品 详情 页 "和 “第 17 间 京东 商品 详情 页 服务 闭环 实践 ”。 


10.5 ”Nginx 代 理 层 缓 存 


10.5.1 Nginx 代 理 层 缓存 配置 
1.HTTP 模 块 配置 


proxy buffering on; 


proxy buffer size 4k; 

proxy buffers 512 4k; 

proxy busy buffers size 64k; 

proxy cache path /export/cache/proxy cache levels-1:2 


keys zone-cache:512m inactive-5m max size-8g use temp path-off; 


#proxy timeout 


proxy connect timeout 38; 
proxy read timeout 58; 
proxy send timeout 557 


proxy_cache_path 指 令 配置 : 


` levels=1:2: ”表示 创建 两 级 目录 结构 ， 绥 存 目 录 的 第 一 级 目录 是 1 个 字 
符 ， 第 二 级 目录 是 2 个 字符 ， UR ee erie les 如 果 将 
所 有 文件 放 在 一 级 目录 下 的 话 ， 文 件 量 很 大 ， 会 导致 文件 访问 变 慢 。 


keys_zone=cache:512m: 设置 存储 所 有 缓存 key 和 相关 信息 的 共享 内 存 
区 ，1M 大 约 能 存储 8000 个 key 。 


- inactive=5m : inactive 指 定 被 缓存 的 内 容 多 和 久 不 被 访问 将 从 缓存 中 移 
除 ， 以 保证 内 容 的 新 鲜 ， 软 认为 10 分 钟 。 


-max_size=8g: 最 大 缓存 靖 值 , “cache manager” 进 程 会 监控 最 大 缓存 大 
小 ， 当 缓存 达到 该 靖 值 时 ， 该 进程 将 从 缓存 中 移 除 最 近 最 少 访问 的 内 


: use temp path : 如 有 果 为 on9， 则 内 容 首 先 被 写 入 临时 文件 

(proxy temp path) ， 然 后 重 命名 到 proxy_cache_path 指 定 的 目录 ; 如 果 
设置 为 of， 则 内 容 直 接 被 写 入 到 proxy_cache_path 指 定 的 目录 ， 如 果 需 
cache 建 议 off 。 (该 特性 是 1.7.10 提 供 的 。) 


2.proxy_cache 配 置 


location = /cache { 
proxy cache cache; 
proxy cache key S$scheme$proxy host$request uri; 
proxy cache valid 200 5s; 
proxy pass http://backend tomcat/cache$is args$args; 
add header cache-status S$upstream cache status; 


缓存 相关 配置 。 
proxy cache: 指定 使 用 哪个 共享 内 存 区 存储 缓存 信息 。 


: proxy cache key : 设置 缓存 使 用 的 key， 默 认为 完整 的 访问 URL， 根 据 
实际 情况 设置 缓存 key 。 

proxy_cache_valid : 为 不 同 的 啊 应 状态 码 设 置 组 FF AY fe] nx 
proxy cache valid 5s， 则 200、301、302 响 应 都 将 被 缓存 。 


proxy_cache_valid 不 是 唯一 设置 缓存 时 间 的 ， 还 可 以 通过 如 下 方式 (优先 
级 从 上 到 下 ) 实现 。 


E 
以 秒 为 单位 的 “X-Accel-Expires” 啊 应 头 来 设置 啊 应 缓存 时 间 。 


如 R 没有 “X-Accel-Expires”， 则 可 以 根据 “Cache- 
Control”、“Expires” 来 设置 啊 应 绥 存 时 间 。 


否则 ， 使 用 proxy_cache_valid 设 置 缓存 时 间 。 


如 果 啊 应 头 包 含 Cache-Control: private/no-cache/no-store ` Set-Cookie, 或 
者 只 有 一 个 Vary 啊 应 头 且 其 值 为 *， 则 虽 应 内 容 将 不 会 被 缓存 。 可 以 使 用 
proxy_ignore_headers 来 包 略 这 些 啊 应 头 。 


: add. header cache-status $upstream_cache_status TEE Min] JV SL FP S JU BR E 
命中 的 状态 。 


HIT: 缓存 命中 ， 直 接 返 回 缓存 中 内 容 ， 不 回 源 到 后 端 。 


MISS: 缓存 未 命中 ， 回 源 到 后 端 获 取 最 新 的 内 容 。 


EXPIRED: 缓存 命中 但 过 期 了 ， 回 源 到 后 端 获取 最 新 的 内 容 。 


UPDATING: 缓存 已 过 期 但 正在 被 别 的 Nginx WorkerZET Sr, RU 
置 了 proxy_cache_use_stale updating 指 令 时 会 存在 该 状态 。 


STALE: 缓存 已 过 期 ， 但 因 后 端 服务 出 现 了 问题 (比如 后 端 服 务 挂 
T) 返回 过 期 的 响应 ， 配 置 了 如 proxy_cache_use_stale error timeout 指 令 后 
会 出 现 该 状态 。 


REVALIDATED: 启用 proxy_cache_revalidate 指 令 后 ， 当 缓存 内 容 
过 期 时 ，Nginx 通 过 一 次 if-modified-since 的 请 求 涉 去 验证 缓存 内 容 是 否 过 
期 ， 此 时 会 返回 该 状态 。 


E 
BYPASS: proxy cache bypass 指令 有 效 时 ， 强 制 回 源 到 后 端 获取 内 
容 ， 即 使 已 经 缓存 了 。 


: proxy. cache min uses: 用 于 控制 请 求 多 少 次 JE Ri] 应 才 被 缓存 。 默 认 
的 “proxy_cache_min_uses 1;” 指 ， 如 琳 绥 存 热点 比较 集中 、 和 存储 有 限 ， 则 
可 以 通过 修改 该 参数 来 减少 缓存 数量 和 写 磁 一 次 数 。 


- proxy. no cache: ”用 于 控制 什么 情况 下 啊 应 不 被 缓 存 。 比 如 配 
置 “proxy_no_cache $args_nocache”， 如 有 果 带 的 nocache 参 数值 至 少 有 一 个 
不 为 空 或 者 为 0， 则 啊 应 将 不 被 缓存 。 


- proxy_cache_bypass: 类 似 于 proxy_no_cache， 但 其 控制 什么 情况 不 使 
用 缓存 的 内 容 ， 而 是 直接 到 后 端 获 取 最 新 的 内 容 。 如 果 命 中 ， 则 
$upstream_cache_status 7JBYPASS ° 


: proxy cache use stale: 当 对 缓存 内 容 的 过 期 时 间 不 敏感 ， 或 者 后 端 服 
务 出 问题 时 ， 即 使 缓存 的 内 容 不 新 鲜 也 总 比 返回 错误 给 用 户 强 〈 类 似 于 
FEIR) ， 此 时 可 以 配置 该 参数 ， 如 “proxy_cache_use_stale error timeout 
http_500 http_502 http_503 http_504”， 即 如 果 出 现 超时 、 后 端 连接 出 错 、 
500/502/503 等 错误 时 ， 则 即使 缓存 内 容 已 过 期 也 先 返 回 给 用 户 ， 此 时 
$upstream cache status7J STALE ° ih — T updating KIR Z& f£ Gt BH H.1E 
在 被 别 的 Nginx Worker 进 程 更 新 ， 只 是 先 返回 了 过 期 内 容 ， 此 时 
$upstream_cache_status 为 UPDATING ° 


* proxy cache revalidate : 当 缓 存 过 期 后 ， 如 采 开 局 了 
proxy_cache_revalidate ， 则 会 发 出 一 次 if-modified-since 或 if-none-match 条 
件 请 求 ， 如 果 后 端 返 回 304 ， 则 此 时 $upstream cache status 为 
REVALIDATED， 我 们 将 得 到 两 个 好 处 ， 节 省 带宽 和 减少 写 磁 副 的 次 数 。 


proxy cache lock: 当 多 个 客户 端 同时 请 求 同 一 份 内 容 时 ， 如 果 开 局 
proxy cache lock 〈 默 认 off) ， 则 只 有 一 个 请 求 被 发 送 至 后 端 。 其 他 请 求 
将 等 竺 该 请 求 的 返回 。 当 第 一 个 请 求 返 回 后 ， 其 他 相同 请 求 将 从 缓存 中 
获取 内 容 返 回 。 当 第 一 个 请 求 超过 了 proxy_cache_lock_timeout 超 时 时 间 

(默认 为 5s) ， 则 其 他 请 求 将 同时 请 求 到 后 端 来 获取 啊 应 ， 且 啊 应 不 会 
被 缓存 〈 在 1.7.8 版 本 之 前 是 被 缓存 的 ) 。 启 用 proxy_cache_lock 可 以 应 对 
Dog-pile effect 〈 当 某 个 缓存 失效 时 ， 同 时 有 大 量 相 同 的 请 求 没命 中 组 
从 而 导致 后 端 压力 太 大 ， 此 时 限制 一 个 请 求 去 
获取 即 可 ) e 


: proxy. cache lock age 是 1.7.8 新 添加 的 ， 如 采 在 proxy_cache_lock_age 指 
定 的 时 间 内 (默认 为 5s) ， 最 后 一 个 发 送 到 后 端 进行 新 缓存 构建 的 请 求 
还 没有 完成 ， 则 下 一 个 请 求 将 被 发 送 到 后 端 来 构建 缓存 (因为 1.7.8 版 本 
Ja, proxy cache lock _timeout 超 时 之 后 返回 的 内 容 是 不 缓存 的 ， 需 要 下 
一 次 请 求 来 构建 啊 应 缓存 ) 。 


10.5.2 ”清理 缓存 


有 时 缓存 的 内 容 是 错误 的 ， 需 要 手工 清理 。Nginx 丙 业 版 提供 了 purger 功 
能 ， 对 于 社区 版 Nginx ， 则 可 以 考虑 使 用 ngx cache purge 
(https://github.com/FRiCKLE/ ngx cache purge) 模块 进行 缓存 清理 。 


location ~ /purge(/.*) { 
allow 127,.,0.0.1; 
deny all; 


proxy cache purge cache$1$is argsSargs; 


ata 问 权 限 ， 如 只 允许 内 网 可 以 访问 或 者 需要 密码 才能 访 
间 。 


到 此 代理 层 缓存 束 介 绍 完 了 ， 通 过 代理 层 绥 存 可 以 解决 很 多 问题 ， 可 以 
参考 “第 17 章 泵 东 商 品 详情 页 服务 闭环 实践 ”。 


10.6 一 些 经 验 


只 缓存 200 状 态 码 的 啊 应 ， 像 302 等 ， 要 根据 实际 场景 决定 。 比 如 ， 当 系 
统 出 错时 ， 目 动 302 到 错误 页 面 ， 此 时 缓存 302 束 不 对 了 。 


- 有 些 页 面 不 需要 强 一 致 ， 可 以 进行 几 秒 的 缓存 。 比 如 商品 详情 页 展示 的 
库存 ， 可 以 缓存 儿 秒 钟 。 短 时 间 的 不 一 致 对 于 用 户 来 说 是 没有 影响 的 。 


: JS/CSS/image 等 一 些 内 容 缓存 时 间 可 以 设置 为 很 人 入 ， 比 如 1 个 月 甚至 1 
年 ， 通 过 在 页 面 修改 版 本 来 控制 过 期 。 


- 假设 商品 详情 页 异步 加 载 的 一 些 数 据 ， 使 用 last-modified 进 行 过 期 控制 ， 
而 服务 器 端 做 了 逻辑 修改 ， 但 内 容 是 没有 修改 的 ， 即 内 容 的 最 后 修改 时 
间 没 变 。 如 果 想 过 期 这 些 异 步 加 载 的 数据 ， 则 可 以 考虑 在 商品 详情 页 添 
加 异步 加 载 数据 的 版 本 号 ， 通 过 添加 版 本 号 来 加 载 最 新 的 数据 ， 或 者 将 
last-modified 时 间 加 1 来 解决 ， 但 这 种 情况 下 使 用 ETag 是 更 好 的 选择 。 


-商品 详情 页 异步 加 载 的 一 些 数据 ， 可 以 考虑 更 长 时 间 的 缓存 ， 比 如 1 个 
月 而 不 是 几 分 钟 。 可 以 通过 MQ 将 修改 时 间 推 送 到 商品 详情 页 ， 从 而 实现 
按 需 过 期 数据 。 


- 服务 器 端 考 虑 使 用 bmpfs 内 存 文件 系统 缓存 、SSD 缓 存 ， 使 用 服务 器 端 负 
载 均 衡 算法 一 致 性 哈 希 来 提升 缓存 命中 率 。 


` 缓存 key 要 合理 设计 。 比 如 ， 去 挥 菜 些 参数 或 排序 参数 ， 以 保证 代理 层 
的 缓存 命中 率 ; 要 有 清理 缓存 的 工具 ， 出 问题 时 能 快速 清理 掉 问 题 key。 


-AB 测 试 /个 性 化 需求 时 ， 要 葵 用 挥 浏 质 亏 组 在 ， 但 和 要 考虑 服务 郁 端 组 
存 。 


为 了 便于 查找 问题 ， 一 般 会 在 响应 关中 添加 源 服务 器 信息 ， 如 访问 季 东 
商品 详情 页 会 看 到 ser 啊 应 头 ， 此 头 存储 了 源 服务 器 耻 ， 以 便 出 现 问 题 
时 ， 知 道 哪 台 服务 右 有 问题 。 
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11 多 级 缓存 


缓存 技术 是 一 个 老生 常 谈 的 话题 ， 但 是 ， 它 也 是 解决 性 能 问题 的 利器 ， 
一 把 瑞士 军刀 。 而 且 在 各 种 面试 过 程 中 ， 或 多 或 少 会 被 问 及 一 些 缓存 相 
关 的 问题 ， 如 缓存 算法 、 热 点 数据 与 更 新 缓存 、 更 新 缓存 与 原子 性 、 组 
存 崩 溃 与 快速 恢复 等 各 种 问题 。 而 这 些 问题 中 ， 有 些 问 题 又 是 与 场景 相 
关 ， 因 此 ， 如 何 合理 应 用 缓存 来 解决 问题 也 是 一 个 选择 题 。 本 文 所 有 内 
容 都 跟 读 服务 缓存 相关 ， 不 会 涉及 写 服务 数据 的 缓存 。 本 文 不 考虑 内 容 
型 应 用 前 置 的 CDN 架 构 ， 也 不 会 涉及 缓存 数据 结构 优化 、 缓 存 空间 利 用 
率 跟 业 务 数据 相关 的 细节 问题 ， 主 要 从 架构 和 提升 命中 率 等 层面 来 探讨 
缓存 方案 。 本 文 将 基于 多 级 缓存 模式 来 介绍 应 用 缓存 时 需要 注意 的 问题 


和 一 些 解决 方案 ， 其 中 一 些 方案 已 经 实现 ， 而 有 一 些 是 正在 党 试用 来 解 
决 痛 点 问题 。 


11.1 多 级 缓存 介绍 


所 谓 多 级 缓存 ， 是 指 在 整个 系统 架构 的 不 同系 统 层 级 进行 数据 缓 企 ， 以 
提升 访问 效率 ， 这 也 是 应 用 最 广 的 方案 之 一 。 我 们 应 用 的 整体 架构 和 流 
程 如 下 图 所 示 。 
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整体 流程 如 下 。 


1. 接 入 Nginx 将 请 求 负载 均衡 到 应 用 Nginx， 此 处 常用 的 负载 均衡 算法 是 轮 

询 或 者 一 致 性 哈 斋 。 轮 询 可 以 使 服务 器 的 请 求 更 加 均衡 ， 而 一 致 性 哈 希 

率 ， 后 续 在 负载 均衡 和 缓存 算法 部 分 我 们 
详细 介绍 。 


2. 应 用 Nginx 读 取 本 地 缓存 【本 地 缓存 可 以 使 用 Lua Shared Dict ^ Nginx 
Proxy Cache (磁盘 /内 存 ) ` Local Redis 实 现 」】。 如 果 本 地 缓存 命中 ， 则 
直接 返回 ， 使 用 应 用 Nginx 本 地 缓存 可 以 提升 整体 的 吞吐 量 ， 降 低 后 端 压 
力 ， 盛 其 应 对 热点 问题 非常 有 效 。 为 什么 要 使 用 Nginx 本 地 缓存 我 们 将 在 
热点 数据 与 缓存 失效 部 分 详细 介绍 。 


3. 如 果 Nginx 本 地 缓存 没命 中 ， 则 会 读 取 相 应 的 分 布 式 缓存 (如 Redis 绥 
AF, EA LAA re EA EM SRR GE ERE A Be), WR 
命中 ， 则 直接 返回 相应 数据 〈 并 回 写 到 Nginx 本 地 缓存 ) 。 


4. 如 果 分 布 式 缓存 也 没有 命中 ， 则 会 回 源 到 Tomcat 集 群 ， 在 回 源 到 Tomcat 
集群 时 ， 也 可 以 使 用 轮 询 和 一 致 性 哈 希 作为 负载 均衡 算法 。 


5. 在 Tomcat 频 用 中 ， 首 先 读 取 本 地 堆 缓存 。 如 果 有 ， 则 直接 返回 (并 会 写 
到 主 Redis 集 群 ) ， 为 什么 要 加 一 层 本 地 堆 缓存 将 在 缓存 崩溃 与 快速 修复 


部 分 详细 介绍 。 


6. 作 为 可 选 部 分 ， 如 采 步 又 4 没有 命中 ， 则 可 以 再 答 试 一 次 读 主 Redis 集 群 
操作 ， 目 的 是 防止 当 从 集群 有 问题 时 的 流量 冲击 。 


dd 缓存 都 没有 命中 ， 则 只 能 查询 DB 或 相关 服务 获取 相关 数据 并 
返回 。 


8 .步骤 7 返回 的 数据 异步 写 到 主 Redis 集 群 ， 此 处 可 能 有 多 个 Tomcat 实 例 同 
时 写 主 Redis 集 群 ， 会 造成 数据 错乱 ， 如 何 解决 该 问题 将 在 更 新 缓存 与 原 
子 性 部 分 详细 介绍 。 


整体 分 了 三 部 分 缓存 : 应 用 Nginx 本 地 缓存 、 分 布 式 缓存 、Tomcat 堆 缓 
存 。 每 一 层 缓存 都 用 来 解决 相关 问题 ， 如 应 用 Nginx 本 地 缓存 用 来 解决 热 
点 缓存 问题 ， 分 布 式 缓存 用 来 减少 访问 回 源 率 ，Tomcat 堆 缓存 用 于 防止 
相关 缓存 失效 / 崩 江 之 后 的 冲击 。 


虽然 都 是 加 缓存 ， 但 是 怎么 加 、 怎 么 用 ， 细 想 下 来 还 是 有 很 多 问题 需要 
权衡 和 考量 的 ， 接 下 来 的 部 分 我 们 束 详 细 来 讨论 一 些 缓存 相关 的 问题 。 


11.2 ”如 何 缓存 数据 
11.2.1 过 期 与 不 过 期 


对 于 缓存 的 数据 我 们 可 以 考虑 不 过 期 缓存 和 带 过 期 时 间 缓存 ， 什 么 场景 
应 该 选择 哪 种 模式 需要 根据 业务 和 数据 量 等 因素 来 决定 。 


不 过 期 缓存 场景 一 般 思路 如 下 图 所 示 。 


rs 1. 开启 事务 


2. 执行 SQL 


3. 提交 事务 


1j 


4. 写 缓存 


使 用 Cache-Aside 模 式 ， 首 先 写 数据 库 ， 如 果 成 功 ， 则 写 缓存 。 这 种 场景 
下 存在 事务 成 功 、 缓 存 写 失 败 但 无 法 回 深 事 务 的 情况 。 为 外 ， 不 要 把 写 
缓存 放 在 事务 中 ， 尤 其 写 分 布 式 绥 存 ， 因 为 网 络 抖动 可 能 导致 写 缓存 啊 
应 时 间 很 慢 ， 引 起 数据 库 事 务 阻塞 。 如 采 对 缓存 数据 一 致 性 要 求 不 是 那 
么 高 ， 数 据 量 也 不 是 很 大 ， 则 可 以 考虑 定期 全 量 同 步 缓存 。 


为 更 好 解决 以 上 多 个 事务 的 问题 ， 可 以 考虑 使 用 “第 15 章 队列 术 ” 中 所 使 
用 的 基于 Canal 实 现 缓存 同步 。 


对 于 长 尾 访 问 的 数据 、 大 多 数 数据 访问 频率 都 很 高 的 场景 ， 或 者 是 缓存 
空间 足够 ， 都 可 以 考虑 不 过 期 缓存 ， 比 如 用 户 、 分 类 、 商 品 、 价 格 、 订 
单 等 。 当 缓存 满 了 ， 可 以 考虑 用 LRU 机 制 张 逐 老 的 缓存 数据 。 


过 期 缓存 机 制 ， 如 采用 懒 加 载 ， 一 般 用 于 缓存 其 他 系统 的 数据 (无 法 订 
阅 变更 消息 ， 或 者 成 本 很 高 ) 、 缓 存 空 间 有 限 、 低 频 热 点 缓存 等 场景 。 
闻 见 步 又 是 首先 读 取 缓 存 ， 如 有 果 不 命 中 ， 则 得 询 数 据 ， 然 后 异步 写 入 组 
存 并 设置 过 期 时 间 ， 下 次 读 取 将 命中 缓存 。 热 点 数据 经 常 使 用 过 期 组 
存 ， 即 在 应 用 系统 上 缓存 比较 短 的 时 间 。 这 种 缓存 可 能 存在 一 段 时 间 的 


数据 不 一 致 情况 ， 需 要 根 据 场景 来 决定 如 何 设置 过 期 时 间 。 如 库存 数据 
可 以 在 前 端 应 用 上 缓存 儿 秒 钟 ， 短 时 间 的 不 一 致 是 可 以 忍受 的 。 


11.2.2 ”维度 化 缓存 与 增 量 缓存 


对 于 电 商 系统 ， 一 个 商品 可 能 拆 成 如 基础 属性 、 图 片 列表 、 上 下 架 、 规 
格 参数 、 商 品 介绍 等 。 如 果 商 品 变更 了 ， 要 把 这 些 数据 都 更 新 一 青 ， 更 
新 成 本 很 高 ， 包 括 接 口 调用 量 和 带宽 。 因 此 ， 最 好 将 数据 进行 维度 化 并 
增 量 更 新 《只 更 新 变 的 部 分 ) 。 尤 其 如 上 下 以 这 种 只 是 一 个 状态 变更 但 
每 天 频繁 调用 的 数据 ， 维 度 化 后 能 减少 服务 很 大 压力 。 


11.2.3 ”大 Value 缓存 


要 警惕 缓存 中 的 大 Value， 尤其 是 使 用 Redis 时 。 过 到 这 种 情况 时 可 以 考虑 
使 用 多 线程 实现 的 缓存 ， 如 Memcached， 来 缓存 大 Value; 或 者 对 Value 进 
TEk: 或 者 将 Value 拆 分 为 多 个 小 Value， 客 户 端 再 进行 查询 、 聚 合 。 


11.24 ”热点 缓存 


对 于 那些 访问 非常 频 迷 的 热点 缓存 ， 如 采 每 次 都 去 远程 缓存 系统 中 获 
取 ， 可 能 会 因为 访问 量 太 大 导致 远程 缓存 系统 请 求 过 多 、 人 负载 过 高 或 者 
带宽 过 高 等 问题 ， 最 终 可 能 导致 缓存 响应 慢 ， 使 客户 端 请 求 超时 。 一 种 
解决 方案 是 通过 挂 更 多 的 从 缓存 ， 客 户 端 通过 人 负载 均衡 机 制 读 取 从 缓存 
系统 数据 。 不 过 也 可 以 在 客户 端 所 在 的 应 用 /代理 层 本 地 存储 一 份 ， 从 而 
避免 访问 远程 缓存 ， 即 使 像 库存 这 种 数据 ， 在 有 些 应 用 系统 中 也 可 以 进 
行 几 秒 钟 的 本 地 缓存 ， 从 而 降低 远程 系统 的 压力 。 


11.3 “分布 式 缓存 与 应 用 负载 均衡 
11.3.1 缓存 分 布 式 


此 处 说 的 分 布 式 缓存 一 般 采 用 分 片 实现 ， 即 将 数据 分 散 到 多 个 实例 或 多 
台 服 务 器 。 算 法 一 般 采 用 取 模 和 一 致 性 哈 布 。 要 采用 如 之 前 所 说 的 不 过 
期 缓存 机 制 ， 可 以 考虑 取 模 机 制 ， 扩 容 时 一 般 是 新 建 一 个 集群 。 而 对 于 
可 以 丢失 的 缓存 数据 ， 可 以 考虑 一 致 性 哈 希 ， 即 使 其 中 一 个 实例 出 问题 
只 是 丢 一 小 部 分 ， 对 于 分 片 实现 可 以 考虑 客户 端 实现 ， 或 者 使 用 如 


Twemproxy 中 间 件 进行 代理 〈 分 片 对 客户 端 是 透明 的 ) 。 如 果 使 用 
Redis， 则 可 以 考虑 使 用 redis-cluster 分 布 式 集群 方案 。 


11.3.2 ”应 用 负载 均衡 


应 用 负载 均衡 一 般 采 用 轮 询 和 一 致 性 哈 希 ， 一 致 性 哈 希 可 以 根据 应 用 请 
求 的 URL 或 者 URL 参 数 将 相同 的 请 求 转发 到 同一 个 节点 。 而 轮 询 是 将 请 
求 均匀 地 转发 到 每 个 服务 器 ， 如 下 图 所 示 。 
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整体 流程 如 下 。 
1. 首 先 ， 请 求 进入 接 入 层 Nginx。 
2. 根 据 负载 均衡 算法 将 请 求 转发 给 应 用 Nginx。 


3. 如 果 应 用 Nginx 本 地 缓存 命中 ， 则 直接 返回 数据 ， 否 则 读 取 分 布 式 缓存 
或 者 回 源 到 Tomcat 。 


轮 询 的 优点 是 ， 到 应 用 Nginx 的 请 求 更 加 均匀 ， 使 得 每 个 服务 器 的 负载 基 
本 均衡 。 轮 询 的 缺点 是 ， 随 着 应 用 Nginx 服 务 器 的 增加 ， 缓 存 的 命中 率 会 
下 降 ， 比 如， 原来 10 台 服务 器 命中 率 为 90%， 再 加 10 台 服务 器 将 可 能 降低 
到 45%。 而 这 种 方式 不 会 因为 热点 问题 导致 其 中 某 一 台 服 务 器 负载 过 重 。 


一 致 性 哈 希 的 优点 十， 相同 请 求 都 会 转发 到 同一 台 服 务 嚣 ， 命 中 率 不 会 
因为 增加 服务 顺 而 降低 。 一 致 性 哈 希 的 缺点 是 ， 因 为 相同 的 请 求 会 转发 
到 同一 台 服 务 器 ， 因 此 ， 可 能 造成 菜 台 服务 右 人 负载 过 重 ， 其 至 因为 请 求 
太 多 导致 服务 出 现 问 题 。 

解决 办 法 是 根据 实际 情况 动态 选择 使 用 哪 种 算法 。 


` 负载 较 低 时 ， 使 用 一 致 性 哈 希 。 


- 热点 请 求 降级 一 致 性 哈 希 为 轮 询 ， 或 者 如 有 果 请 求 数据 有 规律 ， 则 可 考虑 
带 权 重 的 一 致 性 哈 希 。 


.将 热点 数据 推送 到 接 入 层 Nginx， 直 接 响应 给 用 户 。 
11.4 ”热点 数据 与 更 新 缓存 

热点 数据 会 造成 服务 器 压力 过 大 ， 导 致 服务 器 性 能 、 乔 吐 量 、 带 宽 达到 
极限 ， 出 现 响应 慢 或 者 拒绝 服务 的 情况 ， 这 肯定 是 不 允许 的 。 可 以 用 如 
下 几 个 方案 去 解决 


11.4.1 单机 全 量 缓存 + 主 从 


LVS+HAProxy 


从 Redis 集 群 


从 Redis 集 群 


从 Redis 集 群 


如 上 图 所 示 ， 所 有 缓存 都 存储 在 应 用 本 机 ， 回 源 之 后 会 把 数据 更 新 到 主 
Redis 集 群 ， 然 后 通过 主 从 模式 复制 到 其 他 从 Redis 集 群 。 缓 存 的 更 新 可 以 
采用 懒 加 载 或 者 订阅 消息 进行 同步 。 


11.4.2 ”分 布 式 缓存 + 应 用 本 地 热点 


LV9+HAProxy 


Nginx+Lua 


从 Redis 集 群 

Nginx+Lua 
B 机 房 

Nginx+Lua 

从 Redis 集 群 
Nginx+Lua 

更 新 绥 存 一 > 主 Redis 集 群 |- -同步 
| Tomcat | Tomcat | Tomcat 


对 于 分 布 式 缓存 ， 我 们 需要 在 Nginx+Lua 应 用 中 进行 应 用 缓存 来 减少 
Redis 集 群 的 访问 冲击 ， 即 首先 查询 应 用 本 地 缓 在 ， 如 果 命 中 ， 则 直接 组 
存 ， 如 果 没有 命中 ， 则 接着 查询 Redis 集 群 、 回 源 到 Tomcat， 然 后 将 数据 


缓存 到 应 用 本 地 。 


对 于 LVS+HAProxy 到 应 用 Nginx 的 负载 机 制 ， 正 党 情况 采用 一 致 性 哈 硕 ， 

如 果 某 个 请 求 类 型 的 访问 量 突破 了 一 定 的 病 值 ， 则 自动 降级 为 轮 询 机 
制 。 而 对 于 一 些 秒杀 活动 之 类 的 热点 ， 我 们 是 可 以 提前 知道 的 ， 可 以 把 
相关 数据 预先 推送 到 应 用 Nginx， 并 将 负载 均衡 机 制 降级 为 轮 询 。 实 际 场 
景 中 我 们 是 通过 两 级 Nginx ( 接 入 Nginx 一 应 用 Nginx) 实现 该 特性 的 ， 没 


有 在 LVS+HAProxy 层 实现 。 


另外 ， 可 以 考虑 建立 实时 热点 发 现 系统 来 发 现 热点 。 


具体 步骤 如 下 。 
1. 接 入 Nginx 将 请 求 转发 给 应 用 Nginx。 


2. 应 用 Nginx 首 先 读 取 本 地 缓存 。 如 果 命 中 ， 则 直接 返回 ， 不 命中 会 读 取 
分 布 式 缓存 、 回 源 到 Tomcat 进 行 处 理 。 


3. 应 用 Nginx 会 将 请 求 上 报 给 实时 热点 发 现 系 统 ， 如 使 用 UDP 直 接 上 报请 
求 ， 或 者 将 请 求 写 到 本 地 kafka， 或 者 使 用 flume 订 阅 本 地 Nginx 日 志 。 上 
ea 它 将 进行 热点 统计 〈 可 以 考虑 storm 实 时 计 
4. 根 据 设 置 的 国 值 将 热点 数据 推送 到 应 用 Nginx 本 地 缓存 。 


需要 我 们 去 考虑 数据 一 致 性 ， 即 何 时 失效 或 更 新 组 
f ? 

- 如 果 可 以 订阅 数据 变更 消息 ， 那 么 建议 订阅 变更 消息 以 进行 缓存 更 新 。 
- 如 果 无 法 订阅 消息 或 者 订阅 消息 成 本 比较 高 ， 并 且 对 短暂 的 数据 一 致 性 
要 求 不 严格 〈 比 如， 在 商品 详情 页 看 到 的 库存 ， 可 以 短暂 的 不 一 致 ， 只 
oe ， 那 么 可 以 设置 合理 的 过 期 时 间 ， 过 期 后 再 查 
询 新 的 数据 。 


. 如 果 是 秒杀 之 类 的 ， 可 以 订阅 活动 开启 消息 ， 将 相关 数据 提前 推送 到 前 
端 应 用 ， 并 将 负载 均衡 机 制 降级 为 轮 询 。 


- 建立 实时 热点 发 现 系 统 来 对 热点 进行 统一 推送 和 更 新 。 


11.5 ”更 新 缓存 与 原子 性 


正如 之 前 说 的 ， 如 果 多 个 应 用 同时 操作 一 份 数据 ， 很 可 能 导致 缓存 数据 
变 成 及 数据， 解决 办 法 如 下 。 


- 更 新 数据 时 使 用 更 新 时 间 戳 或 者 版 本 对 比 ， 如 有 果 使 用 Redis， 则 可 以 利用 
其 单线 程 机 制 进行 原子 化 更 新 。 


- 使 用 如 canal 订 阅 数据 库 binlog。 


将 更 新 请 求 按照 相应 的 规则 分 散 到 多 个 队列 ， 然 后 每 个 队列 进行 单线 程 
更 新 ， 更 新 时 拉 取 最 新 的 数据 保存 。 


-用 分 布 式 锁 ， 在 更 新 之 前 获取 相关 的 锁 。 


11.6 ”缓存 骨 江 与 快速 修复 
11.6.1 取 模 


对 于 取 模 机 制 ， 如 果 其 中 一 个 实例 坏 了 ， 摘 除 此 实例 将 导致 大 量 绥 存 不 
命中 ， 则 瞬间 大 流量 可 能 导致 后 端 DB/ 服 务 出 现 问题 。 对 于 这 种 情况 ， 可 
以 采用 主 从 机 制 来 避免 实例 坏 了 的 问题 ， 即 其 中 一 个 实例 坏 了 可 以 用 从 / 
主 顶 上 来 。 但 是 ， 取 模 机 制 下 增加 一 个 节点 将 导致 大 量 缓存 不 命中 ， 一 
般 是 建立 男 一 个 集群 ， 然 后 把 数据 迁移 到 新 集群 ， 把 流量 迁移 过 去 。 


11.6.2 ”一致 性 哈 希 
对 于 一 致 性 哈 希 机 制 ， 如 果 其 中 一 个 实例 坏 了 ， 摘 除 此 实例 只 影响 一 致 
性 哈 希 环 上 的 部 分 缓存 不 命中 ， 不 会 导致 大 量 缓存 瞬间 回 源 到 后 端 DB/ 服 
务 ， 但 是 也 会 产生 一 些 影响 。 


ee ee 
SWE? 


11.6.3 ”快速 恢复 
如 果 出 现 之 前 说 到 的 一 些 问题 ， 可 以 考虑 如 下 方案 。 
. 主 从 机 制 ， 做 好 宛 余 ， 即 其 中 一 部 分 不 可 用 ， 将 对 等 的 部 分 补 上 去 。 


如 有 果 因 为 缓存 导致 应 用 可 用 性 已 经 下 降 ， 可 以 考虑 部 分 用 户 降 级 ， 然 后 
慢 慢 减少 降级 量 ， 后 台 通 过 Worker 预 热 缓存 数据 。 


也 就 是 说 ， 如 果 整 个 缓存 集群 坏 了 ， 而 且 没 有 备份 ， 那 么 只 能 慢 慢 将 绥 
存 重 建 。 为 了 让 部 分 用 户 还 是 可 用 的 ， 可 以 根据 系统 承受 能 力 ， 通 过 降 
级 方案 让 一 部 分 用 户 移 用 起 来 ， 将 这 些 用 户 相关 的 缓存 重建 。 另 外 ， 通 
过 后 合 Worker 进 行 缓存 数据 的 预 热 。 


12 ”连接 池 线 程 池 详解 


在 应 用 系统 开发 过 程 中 ， 我 们 经 常会 用 到 池 化 技术 ， 如 对 象 池 、 连 接 
池 、 线 程 池 等 ， 通 过 池 化 来 减少 一 些 消耗 ， 以 提升 性 能 。 对 象 池 通过 复 
用 对 象 从 而 减少 创建 对 象 、 垃 圾 回收 的 开销 ， 但 是 ， 池 不 能 太 大 ， 太 大 
会 影响 GC 时 的 扫描 时 间 。 连 接 池 如 数据 库 连 接 池 、Redis 连 接 池 、HTTP 
连接 池 ， 通 过 复 用 TCP 连 接 来 减少 创建 和 释放 连接 的 时 间 来 提升 性 能 。 线 
程 池 也 是 类 似 的 ， 通 过 复 用 线程 提升 性 能 。 也 就 是 说 池 化 的 目的 就 是 通 
过 复 用 技术 提升 性 能 。 

池 化 可 以 使 用 Apache commons-pool 2 来 实现 ， 比 如 DBCP、Jedis 连 接 池 都 
是 使 用 commons-pool 2 实现 的 ， 最 新 的 版 本 是 2.4.2。 另 外 ， 不 建议 再 使 用 
commons-pool 1.x 版 本 。 而 笔者 也 在 工作 中 写 过 上 自己 的 连接 池 fast-pool 以 


适应 我 们 的 场景 。 本 文 主要 讲解 数据 库 连 接 池 DBCP、HTITP 连 接 池 
HttpClient 和 线程 池 。 


12.1 数据 库 连 搂 池 


数据 库 连 接 池 有 很 多 实现 ， 如 C3P0、DBCP、Druid 等 。 笔 者 用 得 最 多 的 
是 Druid 和 DBCP。 本 文 将 以 commons-dbcp 2 2.1.1 作 为 示例 进行 讲解 。 


12.1.1 DBCP 连 接 池 配置 


<bean id-"dataSource" 

class-"org.apache.commons.dbcp2.BasicDataSource" 
destroy-method-"close"» 

«1-- 数据 库 连 接 相关 配置 (URL、 用 户 名 、 密 码 、 测 试 Query、 默 认 超时 时 间 ) --> 

<property name="url" value=""/> 

<property name-"username" value=""/> 

<property name="password" value=""/> 

<!-- Statement 默认 超时 时 间 ， 单 位 : 秒 --> 

<property name="defaultQueryTimeout" value="3"/> 

«1-- 默认 是 否 自动 提交 事务 ， 默 认为 true --> 


<property name="defaultAutoCommit" value="false"/> 


<! 一 数据 库 连 接 属性 不同 的 数据 库 配置 不 一 样 )--> 
<property name="connectionProperties" 
value="connectTimeout=2000; socketTimeout=2000 "/> 


«1-- 连接 池 队 列 类 型 默认 为 LIFO，false 表示 FIFO --> 

<property name-"lifo" value-"false"/» 

<!-- 建 议 以 下 值 尽量 一 样 ， 没 必要 频繁 地 过 期 空闲 连接 〈 除 非 出 现 连接 池 资 源 紧缺 等 情况 ， 
才 可 以 考虑 ) --> 

«property name-"initialSize" Value="80"/> 

<property name-"minIdle" value="80"/> 

<property name="maxIdle" value="80"/> 

<property name="maxTotal" value="80"/> 


<!-- 这 是 等 待 获取 连接 池 连 接 时 间 ， 也 不 要 太 大 ， 比 如 设置 在 500 毫秒 --> 


<property name-"maxWaitMillis" value-"500" /> 


<!- 验 证 数据 库 连 接 是 否 有 效 / 可 用 --> 

<!-- 从 池 中 获取 连接 时 进行 validateConnection， 默 认为 true --> 

<property name-"testOnBorrow" value="true"/> 

«1-- 新 建 连接 时 进行 validateCconnection， 默 认为 false --> 

<property name-"testOnCreate" value-"false"/» 

«1-- 将 连接 释放 回 池 时 进行 validateCconnection， 默 认为 false --> 

<property name-"testOnReturn" value="false"/> 

<!-- 如 果 不 设 置 ， 则 将 调用 ConnectionfisValid(int timeout) 验证 数据 库 是 否 有 
效 --> 

<property name-"validationQuery" value=""/> 

<!-- 连接 存活 的 最 长 时 间 ，<=0 禁用 该 配置 --> 


<property name-"maxConnLifetimeMillis" value="0"/> 


<!-- 驱除 定时 器 执行 周期 ，<=0 表示 禁用 --> 


<property name-"timeBetweenEvictionRunsMillis" value="0" /> 

«1-- 连接 空闲 多 久 从 池 中 驱除 ，<=0 不 做 判断 --> 

<!-- minIdle < 当前 空闲 连接 数量 ， 使 用 这 个 时 间 测 试 --> 

<property name-"softMinEvictableIdleTimeMillis" value="0"/> 

<!-- 连接 空 采 多 和 久 从 池 中 驱除 , E softMinEvictableIdleTimeMillis 是 或 关系 --> 

Xproperty name-"minEvictableIdleTimeMillis" value="0" /> 

<!-- 每 次 测试 多 少 空 闪 对 象 ，<=0 就 相当 于 禁用 --> 

<property name-"numTestsPerEvictionRun" value="0" /> 

«1-- 当 连 接 空 闪 时 是 否 测 试 ， 即 保持 连接 一 直 存 活 ， 配 合 驱除 定时 器 使 用 --> 

<property name-"testWhileIdle" value="false"/> 

<!-- 判断 连接 是 否 需要 驱除 的 策略 ， 默 认为 DefaultEvictionPolicy --> 

Xproperty name-"evictionPolicyClassName" value-"org.apache.commons. 
pool2.impl.DefaultEvictionPolicy"/» 


«1-- 移 除 无 引用 连接 〈 那 些 没 有 close 的 连接 )， 此 处 设置 为 false， 需 要 保证 程序 中 连 
接 一 定 释放 --> 

<property name="removeAbandonedOnBorrow" value="false"/> 

<property name-"removeAbandonedOnMaintenance" value="false"/> 

«1-- 超时 后 将 自动 关闭 无 引用 连接 ， 单 位 : 秒 --> 


<property name="removeAbandonedTimeout" value="10"/> 


</bean> 


1. 数 据 库 连 接 配 置 


配置 数据 库 连接 URL (url) 、 用 户 名 (username) ^ 密码 (password) 、 
Statement 默认 超时 时 间 (defaultQueryTimeout) 、 事 务 自动 提交 

(defaultAutoCommit) 、 数 据 库 连接 属性 (connectionProperties， 
连接 超时 时 间 等 数据 库 特有 属性 ， 也 可 以 在 JDBC URL 后 面 通 过 
propName=propValue” 配 置 connectionProperties , 更 多 参数 请 人 参 T 
http://dev.mysql.com/doc/connector-j/5. 1/en/connector-j-reference- 
configuration-properties.ht ml) ° 


2. 池 配置 


配置 连接 池 队 列 类 型 \lifo) 是 采用 LIFO 还 是 FIFO 获 取 连 接 ， 默 认为 
FIFO ° 


其 配置 项 包括 初始 大 小 (initialSize) 、 最 小 空 帮 大 小 (minIdle) ^ T 
空闲 大 小 (maxldle) ` 最 大 大 小 (maxTotal) 。 连 接 如 果 不 使 用 则 会 
空闲 ， 因 此 ， 空 闲 连 接 可 以 根据 实际 情况 保持 存活 。 BRE 


可 以 考虑 将 如 上 的 几 个 配置 设置 为 一 样 ， 减 少 过 


还 有 一 个 maxWaitMillis， 人 车 接 池 没 可 用 连接 时 的 最 大 
等 待 时 间 ， 当 超时 后 将 抛 出 异 


3. 验 证 数据 库 连 接 有 效 性 

有 三 种 办 法 : 主动 测试 (创建 连接 时 、 获 取 连 接 时 、 释 放 连 接 时 ) E 
时 测试 (通过 定时 器 定期 测试 ) 、 关 闭 孤 儿 连 接 。 使 用 配置 的 
validationQuery (如 果 不 配 置 默 认 调 用 Connection#isValid 进 行 验 证 ) 和 
maxConnLifetimeMillis (连接 生存 的 最 长 时 间 ) 来 验证 连接 是 否 可 用 。 
主动 测试 


testOnBorrow 是 获取 连接 时 测试 ，testOnCreate 是 创建 连接 时 测试 ， 
testOnReturn 是 释放 连接 时 测试 ， 测 试 代 码 如 下 。 


public boolean validateObject (PooledObject«PoolableConnection» p) { 
try { 
validateLifetime (p); 
validateConnection (p.getObject ()); 
return true; 
} catch (Exception e) { 


return false; // 表 明 当前 连接 要 释放 /销毁 


// 验 证 连接 的 最 大 生存 时 间 ， 如 果 配 置 了 而 且 超出 了 最 大 生存 期 ， 则 抛 出 异常 
private void validateLifetime (PooledObject<PoolableConnection> p) 
throws Exception { 
if (maxConnLifetimeMillis » 0) ( 
long lifetime = System.currentTimeMillis() - p.getCreateTime(); 
if (lifetime > maxConnLifetimeMillis) { 
throw new LifetimeExceededException (Utils. getMessage ( 
"connectionFactory.lifetimeExceeded", 


Long.valueOf(lifetime), 
Long. valueOf (maxConnLifetimeMillis) ) ) ; 


} 

// 发 送 验证 命令 给 底层 数据 库 验 证 存活 ， 

//validationQuery 要 配置 为 至 少 返 回 一 行 记 录 的 SELECT 语句 ; 

// 如 果 不 配置 ， 则 默认 使 用 ConnectionfisValid(int timeout) 测 试 


public void validateConnection(PoolableConnection conn) 
throws SQLException { 


if(conn.isClosed()) { 


throw new SQLException ("validateConnection: connection closed"); 


} 


conn.validate( validationQuery, _validationQueryTimeout) ; 


} 


MySQL Connector 也 提供 了 autoReconnect 和 autoReconnectForPools 配 & 
maxReconnects 来 实现 重 连 。 


if ((this.autoReconnect.getValue()) 
&& (this.autoCommit || this. autoReconnectForPools.getValue()) 
&& this.needsPing && !isBatch) { 
try { 
pingInternal (false, 0); 
this.needsPing = false; 
} catch (Exception Ex) { 
createNewIO (true); 


) 


在 每 次 执行 SQL 之 前 根据 配置 进行 一 次 ping 测 试 。 很 多 人 在 数据 库 连 接 
URL 上 都 配置 了 此 参数 ， 但 MySQL 官 方 不 推荐 这 种 做 法 ， 而 是 推荐 通过 
如 DBCP2 使 用 testOnBorrow 在 获取 连接 时 只 进行 一 次 测试 。 


定时 测试 


使 用 timeBetweenEvictionRunsMillis 配 置 定 时 器 执行 周期 ， 如 果 配 置 为 
<0 , Wl ® zs BA, PEA gm Wl 下 Brom 


(BaseGenericObjectPoolZstartEvictor) ° 


if (delay > 0) { 
evictor = new Evictor(); 
EvictionTimer.schedule(evictor, delay, delay); 


} 


EvictionTimer 是 static， 因 此 一 个 ClassLoader 将 只 有 一 个 Timer 进 行 调度 ， 


主要 做 以 下 两 件 事情 。 


try 1 
evict();//1l. 执行 Evict 任务 


) catch(Exception e) { 


try ( 
ensureMinIdle();//2. 确保 连接 池 最 小 空闲 连接 数 
) catch (Exception e) { 


swallowException(e); 


Evict 任 务 主要 有 以 下 几 件 事情 执行 (GenericObjectPool#evict) 。 
// 获 取 每 次 任务 处 理 的 连接 数量 《防止 连接 池 配 置 过 大 ， 任 务 执行 过 长 ) 


private int getNumTests() { 
int numTestsPerEvictionRun = getNumTestsPerEvictionRun(); 
if (numTestsPerEvictionRun >= 0) { 
return Math.min(numTestsPerEvictionRun, idleObjects.size()); 
} else { 
return (int) (Math.ceil(idleObjects.size() / 
Math.abs((double) numTestsPerEvictionRun))); 


) 


接着 会 调用 EvictionPolicy (2ki\ 7j DefaultEvictionPolicy) 判断 当前 连接 
是 否 需 要 被 释放 。 


evict = evictionPolicy.evict(evictionConfig, underTest, 
idleObjects.size()); 
if (evict) { 
destroy (underTest); 


DefaultEvictionPolicy#evict 
public boolean evict ( 
EvictionConfig config, PooledObject<T> underTest, int idleCount) { 
// 如 果 当 前 连接 的 空闲 时 间 大 于 softMinEvictableIdleTimeMillis 
// 且 当前 空闲 连接 大 于 配置 的 最 小 空闲 连接 ， 
// 或 者 当前 连接 的 空闲 时 间 大 于 mingvictableIdlerimeMillis， 则 表示 需要 释放 连接 
if ((config.getIdleSoftEvictTime() < underTest.getIdleTimeMillis() 
&& config.getMinIdle() < idleCount) 
|| config.getIdleEvictTime() < umerTest.getIdleTimeMillis()) { 
return true; 
} 


return false; 


可 以 配置 evictionPolicyClassName 来 定义 个 性 化 释放 策略 。 


如 果 配 置 了 testWhileIdle=true ， 则 会 调用 factory.validateObject(underTest) 
进行 连接 可 用 测试 。 


4. 关 闭 孤 儿 连 接 


如 果 获 取 连 接 后 一 直 没 有 释放 回 池 中 ， 即 该 连接 泄露 了 ， 如 果 不 关 闭 的 
话 ， 则 会 造成 数据 库 连 接 被 用 完 ， 因 此 ， 可 以 考虑 配置 
removeAbandoned* 进 行 关闭 孤儿 和 连接。 不 过 不 建议 配置 ， 把 代码 写 健 壮 
吧 。 


12.1.2 DBCP 配 置 建议 


如 果 并 发 量 大 则 建议 ， 几 个 池 大 小 设置 为 一 样 ， 禁 用 关闭 孤儿 连接 ， 茜 
用 定时 器 。 配 置 简 化 为 如 下 代码 。 


<bean id="dataSource" 
class-"org.apache.commons.dbcp2.BasicDataSource" 
destroy-method="close"> 
<! 一 省 略 url username password --> 
<property name="defaultQueryTimeout" value="3"/> 
<property name="defaultAutoCommit" value="false"/> 
<property name-"connectionProperties" 
value="connectTimeout=2000; socketTimeout=2000 "/» 
<property name="testOnBorrow" value="true"/> 
<property name-"lifo" value="false"/> 
<! 一 省 略 池 配 置 ( 池 大 小 设置 为 都 一 样 ) --> 
<property name-"maxWaitMillis" value-"500" /> 
<property name-"timeBetweenEvictionRunsMillis" value="0" /> 
</bean> 


如 果 并 发 量 不 大 则 建议 ， 可 以 按 需 设置 池 大 小 ， 禁 用 关闭 孤儿 连接 ， 局 
prm (注意 MySQL 空 闲 连 接 8 小 时 自动 断 开 ) 。 配 置 简 化 为 如 下 代 
码 。 


<bean id-"dataSource" 

class-"org.apache.commons.dbcp2.BasicDataSource" 
destroy-method="close"> 

<! 一 省 略 url username password --> 

<property name="defaultQueryTimeout" value="3"/> 

<property name="defaultAutoCommit" value="false"/> 

<property name-"connectionProperties" 

value="connectTimeout=2000; socketTimeout=2000 "/> 

<property name="testOnBorrow" value="false"/> 

<property name-"lifo" value="false"/> 

<! 一 省 略 池 配 置 ( 池 大 小 设置 为 都 一 样 ) --> 


<property name-"maxWaitMillis" value="500" /> 


<property name="timeBetweenEvictionRunsMillis" value="3600000"/> 
<property name-"numTestsPerEvictionRun" value="80" /> 


<property name-"testWhileIdle" value="true"/> 
</bean> 


不 管 你 用 哪 种 方式 都 要 记得 设置 超时 时 间 ， 在 JVM 关 闭 / 重 启 时 一 定 要 销 
Boe Re (bean 配 置 destroy-method="close") ， 因 为 如 果 没 有 加 destroy- 
method ， 而 且 重 启 次 数 太 频繁 ， 将 造成 重启 tomcat 后 旧 的 数据 库 连 接 池 
的 连接 不 释放 ， 这 样 会 有 很 多 数据 库 连 接 在 一 段 时 间 内 不 释放 ， 造 成 局 
动 后 无 法 建立 连接 。 


如 下 是 我 们 实际 工程 的 配置 ， 已 经 将 参数 都 默认 化 了 。 


<ds:datasource 
id="orderDataSource" 
url="$ {mysql.order.url}" 
username="$ {mysql.order.username}" 


password="$ {mysql.order.password}" 
max-pool-size="50"/> 


对 于 MySQL ， 因 为 设置 了 Statement 超 时 时 间 ， 超 时 则 要 杀 掉 Statement 。 
MySQL 通 过 Timer 去 完成 这 件 事 情 ， 人 连接 创建 时 会 创建 一 个 Timer， 
执行 Statement 时 给 Timer 分 配 一 个 任务 ， 超 时 则 要 杀 掉 该 Statement。 


timeoutTask = new StatementImpl.CancelTask (this) ; 
//Timer 是 惰性 创建 


conn.getCancelTimer().schedule(timeoutTask, ( long)this.queryTimeout * 
1000); 


CancelTask 会 启动 一 个 新 线程 来 执行 如 下 逻辑 。 


if(queryTimeoutKillsConnection == true) { 
//force close connection 
} else { 
//send “KILL QUERY ConnectionId” to mysql 
} 


如 ES 我 们 配 E T <property 
name="connectionProperties"value="queryTimeoutKills 


os true"/>， 那 么 将 强制 关闭 连接 。 默 认 false， 会 通过 创建 一 个 新 
连接 ， 然 后 执行 “KILL QUERY connectionId” 来 杀 掉 此 连接 当前 执行 的 
SQL ° 


12.1.3 ”数据 库 驱 动 超时 实现 

MySQL 了 驱动 在 创建 每 个 连接 时 会 创建 一 个 Timer (每 个 Timer 是 一 个 

Thread) 。 然 后 每 个 连接 中 创建 的 每 个 Statement 会 提交 一 个 TimerTask 
(超时 则 每 个 Task 在 执行 时 会 创建 并 启动 一 个 新 的 Thread) 。 


也 就 是 说 ， 假 设 一 个 数据 库 连 接 池 创建 了 500 个 连接 ， 每 个 连接 执行 1 个 
statement， 最 坏 的 情况 下 会 创建 : 


500x1+500x1=1000 个 线程 。 
假设 一 个 应 用 中 有 三 个 MySQL 数 据 库 连 接 池 ， 那 么 最 坏 情况 下 有 : 
1000x3=3000 个 线程 创建 


or 了 分 库 分 表 或 者 读 写 分 离 ， 那 么 超时 市 来 的 影响 可 想 而 
H e 


而 Oracle 采 用 不 同 的 策略 一 一 每 个 ClassLoader 一 个 watchdog 线程 (类 似 于 
MySQL 的 timer) 。 每 个 Statement 一 个 Task， 而 线程 是 在 watchdog 需 要 取 


消 时 去 触发 的 ， 即 watchdog 发 现 该 Statement 需 要 cancel 时 ， 调 用 其 某 个 方 
法 ， 该 方法 快速 创建 线程 并 运行 。 


也 就 是 ， 说 假设 我 们 有 500 个 连接 池 ， 每 个 连接 执行 1 个 Statement， 最 坏 
的 情况 下 会 创建 : 


1+500x1=501 个 线程 。 
假设 一 个 应 用 中 有 三 个 MySQL 库 ， 那 么 最 坏 情况 下 有 : 
1 + 500x3=1501 个 线程 创建 。 


12.1.4 ”连接 池 使 用 的 一 些 建 议 


一 是 要 注意 网 络 阻塞 /不 稳定 时 的 级 联 殖 应 (比如 笔者 写 的 ssdb-client 在 网 
络 出 现 故障 如 网 络 不 可 用 时 ， 会 设置 一 个 时 间 ， 在 这 个 时 间 内 的 请 求全 
部 timemout) 。 连 接 池 内 部 应 该 根据 当前 网 络 的 状态 (比如 超时 次 数 太 
ZB) ， 对 于 一 定时 间 内 的 (如 100ms) 全 部 timeout， 根 本 不 进行 
await(tmaxWaibD， 即 有 熔断 和 快速 失败 机 制 。 


还 有 就 是 当前 等 待 连接 池 的 人 数 ， 比 如 现在 等 待 1000 个 ， 那 么 接 下 来 的 
等 待 是 没有 意义 的 ， 这 样 还 会 造成 滚雪球 效应 。 


二 是 等 待 超时 应 该 尽 可 能 小 点 (除非 很 必要 ) 。 即 使 返回 错误 页 ， 也 比 
等 待 并 阻塞 强 。DBCP 比 较 容 易 出 的 问题 就 是 设置 超时 时 间 太 长 ， 造 成 大 
量 TIMED_WAIT 和 线程 阻塞， 而 且 像 深 雪 球 ， 一 旦 出 问题 很 难 立 即 恢 
复 ， 但 可 以 通过 上 文中 的 方案 解决 。 


本 文通 过 DBCP 2 解释 了 在 使 用 连接 池 时 要 注意 的 一 些 参数 配置 ， 不 管 使 
用 什么 连接 池 组 件 ， 其 原理 基本 类 似 。 如 果 你 对 性 能 追求 没有 那么 极 
致 ， 则 使 用 DBCP 2 已 经 够 用 了 。 如 采 你 对 性 能 要 求 非常 高 ， 可 以 用 阿里 
开源 的 Druid， 或 者 号 称 性 能 最 好 的 Java 数 据 库 连接 池 HikariCP 等 ， 笔 者 
在 实际 项 目 中 使 用 较 多 的 是 Druid 。 


12.2 ”HttpClient 连 接 池 


在 实际 项 目 中 ， 我 们 使 用 HttpClient 进 行 HITP 服 务 访 问 ， 笔 者 用 过 
HttpClient 3.x、4.x。 目 前 最 新 版 本 是 5.x (官方 文档 说 5.x 未 来 会 加 入 
HTTP/2 作 为 主要 传输 协议 ) 。 而 3.x、4.x 和 5.x API 是 完全 不 兼容 的 ， 用 
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起 来 很 痛苦 。4.3.x 和 4.2.xX API 也 有 一 些 升级 ， 但 是 向 后 兼容 。 本 文 将 介绍 
4.5.2、4.2.3、3.1 这 三 个 版 本 的 连接 池 配 置 和 一 些 问题 。 


12.2.1 HttpClient 4.5.2 配 置 


static PoolingHttpClientConnectionManager manager = null; 


static CloseableHttpClient httpClient - null; 
public static synchronized CloseableHttpClient getHttpClient () 
if (httpClient == null) { 
// 注 册 访 问 协议 相关 的 Socket 工厂 
Registry<ConnectionSocketFactory> socketFactoryRegistry = 
RegistryBuilder.<ConnectionSocketFactory>create() 
.register("http", PlainConnectionSocketFactory. INSTANCE) 


{ 


.register ("https", 
SSLConnectionSocketFactory.getSystemSocketFactory()) 


.build(); 
//HttpConnection LJ : 配置 写 请 求 /解析 响应 处 理 器 
HttpConnectionFactory«HttpRoute, ManagedHttpClientConnection» 

connFactory = new ManagedHttpClientConnectionFactory( 

DefaultHttpRequestWriterFactory.INSTANCE, 

DefaultHttpResponseParserFactory.INSTANCE); 


//DNS 解析 器 
DnsResolver dnsResolver = SystemDefaultDnsResolver.INSTANCE; 


/ /创建 池 化 连接 管理 器 
manager = new PoolingHttpClientConnectionManager ( 
socketFactoryRegistry, connFactory, dnsResolver); 


// 默 认为 Socket 配置 

SocketConfig defaultSocketConfig = SocketConfig.custom() 
.setTcpNoDelay (true) .build(); 

manager.setDefaultSocketConfig (defaultSocketConfig) ; 


manager.setMaxTotal (300) 7// 设 置 整个 连接 池 的 最 大 连接 数 

// 每 个 路 由 的 默认 最 大 连接 ， 每 个 路 由 实际 最 大 连接 数 默认 为 
//DefaultMaxPerRoute 控制 ， 而 MaxTotal 是 控制 整个 池子 最 大 数 

// 设 置 过 小 无 法 支持 大 并 发 (ConnectionPoolTimeoutException: 

//Timeout waiting for connection from pool)， 路 由 是 对 maxTotal 的 细 分 
manager.setDefaultMaxPerRoute (200) ;// 每 个 路 由 最 大 连接 数 

// 在 从 连接 池 获 取 连 接 时 ， 连 接 不 活跃 多 长 时 间 后 需要 进行 一 次 验证 ， 默 认为 2s 
manager.setValidateAfterlInactivity(5 * 1000); 


// 默 认 请 求 配置 

RequestConfig defaultRequestConfig = RequestConfig.custom() 
.setConnectTimeout (2 * 1000)// 设 置 连接 超时 时 间 ，2s 
.setSocketTimeout (5 * 1000)// 设 置 等 待 数据 超时 时 间 ，5s 
.setConnectionRequestTimeout (2000) 
// 设 置 从 连接 池 获 取 连 接 的 等 待 超时 时 间 
.build(); 


// 创 建 HttpClient 
httpClient = HttpClients.custom() 
.setConnectionManager (manager) 
.setConnectionManagerShared (false) // 连 接 池 不 是 共享 模式 
.evictIdleConnections(60, TimeUnit.SECONDS) 
// 定 期 回收 空闲 连接 
.evictExpiredConnections() // 定 期 回收 过 期 连接 
.SetConnectionTimeToLive (60, TimeUnit.SECONDS) 
// 连 接 存 活 时 间 ， 如 果 不 设置 ， 则 根据 长 连接 信息 决定 
.SetDefaultRequestConfig(defaultRequestConfig) 
// 设 置 默认 请 求 配置 
.SetConnectionReuseStrategy (DefaultConnectionReuseStrategy 
.INSTANCE) / /连接 重用 策略 ， 即 是 否 能 keepAlive 
.setKeepAliveStrategy (DefaultConnectionKeepAliveStrategy 
.INSTANCE) / /长 连接 配置 ， 即 获取 长 连接 生产 多 长 时 间 
.SetRetryHandler (new DefaultHttpRequestRetryHandler (0, 
false)) // 设 置 重 试 次 数 ， 默 认 是 3 次 ， 当 前 是 禁用 掉 ( 根 据 需 要 开启 ) 
.build(); 


//JNM 停止 或 重启 时 ， 关 闭 连接 池 释 放 掉 连接 〈 跟 数据 库 连 接 池 类 似 ) 
Runtime.getRuntime().addShutdownHook(new Thread() { 


@Override 
public void run() { 
try { 
httpClient.close(); 
} catch (IOException e) { 


e.printStackTrace(); 


) 


}); 
} 
return httpClient; 


通过 maxtTotal 和 defaultMaxPerRoute 限 制 ， 每 个 路 由 (IP+PORT) 最 多 创 
建 defaultMaxPerRoute 个 连接 ， 且 所 有 路 由 总 连接 数 不 超 过 maxTotal， 即 
maxtTotal 是 整个 池子 的 大 小 ，defaultMaxPerRoute 是 每 个 路 由 的 大 小 。 比 
如 maxtTotalj=300、defaultMaxPerRoute=200， 连 接 到 http:/Vjd.com 时 ， 到 这 
个 主机 的 并 发 最 多 只 有 200 而 不 是 400。 连 接 到 http://jd.com 和 http://qq.com 
时 ， 到 每 个 主机 的 并 发 最 多 只 有 200， 但 总 的 并 发 连接 数 为 300。 


也 可 以 通过 如 下 方法 为 某 个 路 由 单独 设置 其 连接 数 大 小 。 
manager.setMaxPerRoute(new HttpRoute(new HttpHost("jd.com", 80)), 100); 


setConnectionManager 方 法 用 于 配置 HttpClient 使 用 的 连接 池 ， 而 
setConnectionManagerShared 方 法 用 于 配置 此 连接 池 是 否 在 多 个 HttpClient 
之 间 共 享 (默认 为 false) ， 如 果 共 享 的 话 ， 那 么 如 IdleConnectionEvictor 
就 不 能 每 个 HttpClient 一 个 ， 而 只 需要 定义 一 个 即 可 。 


通过 evictIdleConnections 和 evictExpiredConnections 方 法 配置 一 个 后 台 线 程 
定期 释放 过 期 连接 和 空闲 连接 。 HttpClientBuilder 将 创建 
IdleConnectionEvictor 并 定期 进行 过 期 ， 如 果 连 接 池 是 共享 的 ， 多 个 
HttpClient 共 用 一 个 连接 池 ， 则 这 两 个 配置 无 效 。 


if (!this.connManagerShared) {// 只 有 连接 池 是 非 共 享 模式 时 

final HttpClientConnectionManager cm = connManagerCopy; 

/ /创建 释放 连接 定时 器 ， 其 测试 周期 使 用 maxIdleTime， 如 果 不 配 ， 则 默认 为 5s 

if (evictExpiredConnections || evictIdleConnections) { 

final IdleConnectionEvictor connectionEvictor - 
new IdleConnectionEvictor( 

cm, 
maxIdleTime > 0 ? maxIdleTime : 10, 


maxlIdleTimeUnit !- null ? 
maxlIdleTimeUnit : TimeUnit.SECONDS) ; 


// 添 加 HttpClient#close 回调 ， 当 关闭 HttpClient 时 ， 自 动 关闭 该 定时 器 
closeablesCopy.add(new Closeable() { 
@Override 
public void close() throws IOException { 
connectionEvictor.shutdown () ; 


})? 


connectionEvictor.start(); 


} 
// 添 加 HttpClient#close 回调 ， 当 关闭 BttpClient 时 自动 关闭 连接 池 
closeablesCopy.add(new Closeable() { 
@Override 
public void close() throws IOException { 
cm. shutdown () ; 


IdleConnectionEvictor 核心 代码 如 下 。 


while (!Thread.currentThread().isInterrupted()) { 
Thread.sleep(sleepTimeMs); 
connectionManager.closeExpiredConnections(); 
if (maxIdleTimeMs > 0) { 
connectionManager.closeIdleConnections (maxIdleTimeMs, 
TimeUnit.MILLISECONDS); 
) 


在 进行 释放 过 期 连接 和 空闲 连接 时 ，IdleConnectionEvictor 会 周期 性 调用 
dq 和 closeIdleConnections 这 两 个 方法 ， 但 它们 的 实现 
是 通过 一 把 大 的 锁 锁 住 了 整个 连接 池 ， 人 然后 进行 和 历 。 另 外 ， 建 议 只 局 
用 closeExpiredConnections， 这 需要 HTTP 服 务 生产 者 在 返 ERES 中 包含 超 
时 时 间 “Keep-Alive: timeout=time”， 这 样 束 不 需要 使 用 
closeldleConnections 进 行 过 期 空间 连接 了 。 


使 用 HttpClient 时 ， 要 按照 如 下 模式 使 用 。 


HttpResponse response = null; 


try { 
HttpGet get = new HttpGet("http://item.jd.com/2381431.html"); 
response = getHttpClient().execute (get); 
if(response.getStatusLine().getStatusCode() !- HttpStatus.SC OK) { 


EntityUtils.consume(response.getEntity()); 
//error 

} else { 
String result = EntityUtils.toString(response.getEntity()); 
//ok 

} 

} catch (Exception e) { 

if(response != null) { 
EntityUtils.consume(response.getEntity()); 

} 


要 使 Hj EntityUtils.consume(response.getEntity()) 或 者 EntityUtils.toString 
(response.getEntity()) 消 费 响 应 体 ， 不 推荐 HttpEntity#getContent#close 方 法 
来 释放 连接 ， 处 理 不 好 异常 将 导致 连接 不 释放 ， 也 不 推荐 使 用 
CloseableHttpResponse#tclose 关 闭 连 接 ， 它 将 直接 关闭 Socket， 导 致 长 连接 
不 能 复 用 。 


须要 注意 的 是 : 


ae us 如 果 是 短 连 返 ， 则 只 是 作为 一 个 信 
量 来 限制 总 请 求 数 ， 连 接 并 没有 实现 复 用 。 


JVM 在 停止 或 重启 时 ， 记 得 关闭 连接 池 释 放 连 接 


` HttpClient 是 线程 安全 的 ， 不 要 每 次 使 用 创建 一 个 。 


- 如 打 连 接 池 配置 得 比较 大 ， 则 可 以 考虑 创建 多 个 HttpClient 实 例 ， 而 不 是 
使 用 一 个 HttpClient 实 例 。 


连接 池 时 ， 要 尽快 消费 啊 应 体 并 释放 连接 到 连接 池 ， 不 要 保持 太 


12.2.2 ”HttpClient 连 接 池 源码 分 析 


连接 池 实 现代 码 (MainClientExec#execute) 。 
//1. 发 送 请 求 并 接收 响应 


response = requestExecutor.execute(request, managedConn, context); 


//2. 判断 响应 是 否 是 长 连接 ， 即 可 复 用 
if (reuseStrategy.keepAlive(response, context)) { 
//3. 获取 长 连接 超时 周期 (如 果 服 务 器 端 没 设置 ， 则 认为 永 不 过 期 ) 
final long duration = keepAliveStrategy.getKeepAliveDuration (response, 
context); 


//4. 设置 过 期 周期 ， 并 标记 连接 为 可 复 用 
connHolder.setValidFor(duration, TimeUnit.MILLISECONDS); 


connHolder.markReusable(); 


) else {// 标 记 连 接 不 可 复 用 


connHolder.markNonReusable(); 


) 


È 下来， 看 看 哪些 连接 可 以 E 用 
(DefaultConnectionReuseStrategy#keepAlive) 。 


- 如 果 有 了 啊 应 头 “Transfer-Encoding” 且 不 是 “chunked”， 则 不 能 复 用 。 
- 如 果 没 有 了 啊 应 头 “Transfer-Encoding”， 如 果 啊 应 状态 码 为 status >= 


HttpStatus.SC OK && status != HttpStatus.SC NO CONTENT && status 
I= 


HttpStatus.SC_NOT_MODIFIED && status l= 
HttpStatus.SC RESET CONTENT, 


如 果 没 有 响应 头 “Content-Length”， 则 不 能 复 用 ， 如 果 响 应 头 为 


*Content-Length"»- 0， 则 可 复 用 ， 否 则 不 能 复 用 。 


- 啊 应 头 “Connection” 或 “Proxy-Connection” 为 “Close” 不 能 复 用 。 


- HTTP/1.1 BW (7 A Mn] hy A “Connection:Keep-Alive”, PRUE A; 而 
HTTP/1.0:4 JUR He] bv 3. “Connection:Keep-Alive” 7 fe Hj ° 


a EST TR] 38b SE BA An] V SL “Keep-Alive: timeout=time” 中 的 time 实 现 的 ， 
SATA SLEW A DefaultConnectionKeepAliveStrategy ° 


当 我 们 使 用 EntityUtils 消 费 内 容 时 (如 用 consume 方 法 ， 会 将 连接 释放 
回 连接 池 ， 这 也 是 为 什么 让 大 家 获取 到 啊 应 后 尽快 消费 的 原因 ， 在 释放 
连接 时 有 如 下 代码 。 


if (reusable) (//1. 如 果 可 以 复 用 ， 则 释放 到 池 中 
this.manager.releaseConnection( 
this.managedConn, this.state, this.validDuration, this.tunit); 
) else (//2. 不 可 以 复 用 
//2.1 关 闭 物理 连接 ( 即 Socket) 
this.managedConn.close(); 
//2.2 连接 还 是 会 释放 到 池 中 《按照 之 前 说 的 就 是 一 个 信号 量 的 作用 ， 
// 且 物理 连接 每 次 都 关闭 ) 
this.manager.releaseConnection( 
this.managedConn, null, 0, TimeUnit.MILLISECONDS); 


12.2.3 HttpClient 4.2.3É E 


如 下 是 HttpClient 4.2.3 配 置 。 


public static synchronized HttpClient getHttpClient() { 
if (httpClient == null) { 
// 设置 组 件 参 数 ，HTTP 协议 的 版 本 ,1.1/1.0/0.9 


HttpParams params = new BasicHttpParams(); 


// 设 置 连接 超时 时 间 
Integer CONNECTION TIMEOUT = 2 * 1000;  ”// 设 置 请 求 超时 为 2s 
Integer SO TIMEOUT = 2 * 1000; // 设 置 等 待 数据 超时 时 间 为 5s 
Long CONN MANAGER TIMEOUT = 1L * 1000; 
// 定 义 了 当 从 ClientConnectionManager 中 检索 ManagedClientConnection 
// 实 例 时 使 用 的 毫秒 级 的 超时 时 间 
params.setIntParameter (CoreConnectionPNames.CONNECTION TIMEOUT, 
CONNECTION TIMEOUT); 
params.setIntParameter (CoreConnectionPNames.SO TIMEOUT, 
SO TIMEOUT); 
// 在 提交 请 求 之 前 测试 连接 是 否 可 用 


params ,SetBooleanParameter (CoreConnectionPNames.STALE CONNECTION CHECK, 
true); 

// 这 个 参数 期 望 得 到 一 个 3ava.lang.Long 类 型 的 值 。 如 果 这 个 参数 没有 被 设置 ， 

// 则 连接 请 求 就 不 会 超时 无 限 大 的 超时 时 间 ) 

params.setLongParameter (ClientPNames.CONN MANAGER TIMEOUT, 
CONN MANAGER TIMEOUT); 

PoolingClientConnectionManager conMgr - new PoolingClientConnection 
Manager(); 

conMgr.setMaxTotal (300) ;// 设 置 最 大 连接 数 

// 是 每 个 路 由 的 默认 最 大 连接 

conMgr.setDefaultMaxPerRoute (100); 

// 设 置 访问 协议 

conMgr.getSchemeRegistry().register(new Scheme("http", 80, 
PlainSocketFactory. getSocketFactory())); 

conMgr.getSchemeRegistry().register(new Scheme("https", 443, 
SSLSocketFactory.getSocketFactory())); 

httpClient = new DefaultHttpClient(conMgr, params); 

httpClient.setHttpRequestRetryHandler (new 
DefaultHttpRequestRetryHandler(0, false)); 

httpClient.setKeepAliveStrategy (new 
DefaultConnectionKeepAliveStrategy()); 

manager = conMgr; 

) 
return httpClient; 


HttpClient 4.2.3 Bk V 18 fE HE IdleConnectionEvictor, ， 需 要 目 己 实现 。 
HttpClient 3.x 就 不 介绍 了 人 ， 因 为 其 使 用 synchronized+wait+notifyAll。 现 在 
存在 两 个 问题 ， 量 大 时 synchronized 慢 有 旦 notifyAll 可 能 造成 线程 饥饿 。 


httpclient 4.x 使 用 ReentrantLock (默认 非 公平 ) + Condition (每 个 线程 一 
^) 。 在 笔者 机 器 上 (jdk1.6.0_43) 测试 结果 锁 的 优势 明显 比较 大 。 


1x synchronized {} with 32 threads took 2.621 seconds 
1x Lock.lock()/unlock() with 32 threads took 1.951 seconds 
1x synchronized {} with 64 threads took 2.621 seconds 


1x Lock.lock()/unlock() with 64 threads took 1.983 seconds 


12.2.4 ”问题 示例 


此 处 有 一 个 库存 项 目的 例子 ，HttpClient 一 天 并 发 量 在 1500 万 左右 ， 峰 值 
每 秒 7 万 。 在 之 前 使 用 过 程 中 ， 一 直 存 在 大 量 的 如 下 提示 ° 


org.apache.http.conn.ConnectionPoolTimeoutException: Timeout waiting f 
or connection from pool 

atorg.apache.http.impl.conn.PoolingClientConnectionManager.leaseConnec 
tion(PoolingClientConnectionManager.java:232) 

atorg.apache.http.impl.conn.PoolingClientConnectionManager$1.getConnec 
tion(PoolingClientConnectionManager.java:199) 

at org.apache.http.impl.client.DefaultRequestDirector.execute (DefaultR 
equestDirector.java:456) 


通过 jstack 查 看 线程 ， 会 发 现 如 下 代码 。 


"pool-21-thread-3" prio=10 tid=0x00007f6b7c002800 nid=0x40ff waiting on 
condition [0x00007£6b37020000] 

java.lang.Thread.State: TIMED WAITING (parking) 

at sun.misc.Unsafe.park(Native Method) 

- parking to wait for <®00000000f97918b8> (a ava.util.concurrent.locks. 
AbstractQueuedSynchronizer$ConditionObject) 

at java.util.concurrent.locks.LockSupport.parkUntil (LockSupport.java:239) 

at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject. 
awaitUntil (AbstractQueuedSynchronizer.java:2072) 

at org.apache.http.pool.PoolEntryFuture.get (PoolEntryFuture.java:100) 

at org.apache.http.impl.conn.PoolingClientConnectionManager. 
leaseConnection (PoolingClientConnectionManager.java:212) 


原因 是 因为 使 用 了 连接 池 ， 但 连接 不 够 用 ， 造 成 大 量 的 等 待 。 而 且 这 种 
SS ED AR SERA UM, (和 交易 组 之 前 使 用 的 apache common dbcp 存 在 的 
风险 是 类 似 的 ) 。 当 时 使 用 的 是 HttpClient 3.1, 34/1712 8l T 4.2.3 ° 而且 
当时 出 问题 的 一 个 原因 是 使 用 人 员 对 参数 不 了 解 ， 随 意 设 置 其 值 ， 不 出 
现 问题 则 好 ， 出 现 问题 很 难 排查 到 原因 。 因 此 ， 建 议 大 家 按照 本 文 说 的 
进行 参数 设置 。 


还 有 一 个 问题 是 RequestConfig 默认 开启 了 压缩 支持 
(contentCompressionEnabled) ， 其 会 注册 RequestAcceptEncoding (自动 
添加 请 求 涉 Accept-Encoding: gzip,deflate ) 和 ResponseContentEncoding 
〈 上 自动 解压 并 移 除 啊 应 头 Content-Length ^ Content-Encoding ^ Content- 
MD5) ， 所 以 通过 HttpResponse 获 取 不 到 这 几 个 响应 头 也 不 要 奇怪 。 如 果 
需要 这 几 个 头 ， 则 可 以 写 目 己 的 HttpResponseInterceptor 拦 截 器 进行 处 
理 。 


12.3 ”线程 池 


线程 池 的 目的 类 似 于 连接 池 ， 通 过 减少 频 和 党 创建 和 销毁 线程 来 降低 性 能 
损耗 。 每 个 线程 都 需要 一 个 内 存 栈 ， 用 于 存储 如 局 部 变量 、 操 作 栈 等 信 
息 ， 可 以 通过 -Xss 参 数 来 调整 每 个 线程 栈 大 小 (64 位 系统 默认 1024KB， 
可 以 根据 实际 情况 调 小 ， 比 如 256KB) ， 通 过 调整 该 参数 可 以 创建 更 多 
的 线程 ， 不 过 JVM 不 能 无 限制 地 创建 线程 ， 通 过 使 用 线程 池 可 以 限制 创 
建 的 线程 数 ， 从 而 保护 系统 。 线 程 池 一 般配 合 队 列 一 起 工作 ， 使 用 线程 
池 限 制 并 发 处 理 任务 的 数量 。 然 后 设置 队列 的 大 小 ， 当 任务 超过 队列 大 
小 时 ， 通 过 一 定 的 拒绝 策略 来 处 理 ， 这 样 可 以 保护 系统 免 受 大 流量 而 导 
致 月 误 一 一 只 是 部 分 拒绝 服务 ， 还 是 有 一 部 分 是 可 以 正常 服务 的 。 


线程 池 一 般 有 核心 线程 池 大 小 和 线程 池 最 大 大 小 配置 ， 当 线程 池 中 的 线 
程 空 内 一 段 时 间 时 将 会 被 回收 ， 而 核心 线程 池 中 的 线程 不 会 被 回收 。 


核心 线程 池 外 的 线程 空闲 
一 段 时 间 后 将 会 回收 


核心 线程 池 的 线程 一 直 存 
在 ， 不 会 被 回收 


多 少 个 线程 合适 呢 ? 建议 根据 实际 业务 情况 来 压 测 决 定 ， 或 者 根据 利 特 
尔 法 则 来 算出 一 个 合理 的 线程 池 大 小 ， 其 定义 是 ， 在 一 个 稳定 的 系统 
中 ， 长 时 间 观 察 到 的 平均 用 户 数量 L， 等 于 长 时 间 观 察 到 的 有 效 到 达 速 率 
) 与 平均 每 个 用 户 在 系统 中 花费 的 时 间 的 乘积 ， 即 L= XW。 但 实际 情况 是 
复杂 的 ， 如 存在 处 理 超时 、 网 络 拌 动 都 会 导致 线程 花费 时 间 不 一 样 。 因 
此 ， 还 要 考虑 超时 机 制 、 线 程 隔离 机 制 、 快 速 失败 机 制 等 ， 来 保护 系统 
免 草 大 量 请 求 或 异常 情况 的 冲击 。 


Java 提 供 了 ExecutorService 的 三 种 实现 。 


- ThreadPoolExecutor: 标准 线程 池 ° 

- ScheduledThreadPoolExecutor: ”支持 延迟 任务 的 线程 汇 。 

: ForkJoinPool: ”类 似 于 ThreadPoolExecutor， 但 是 使 用 work-stealing 模 
式 ， 其 会 为 线程 池 中 的 每 个 线程 创建 一 个 队列 ， 从 而 用 work-stealing ( 任 


FAM) 算法 使 得 线程 可 以 从 其 他 线程 队列 里 窃取 任务 来 执行 。 即 如 果 
目 己 的 任务 处 理 完 成 了 ， 则 可 以 去 从 碌 的 工作 线程 那里 镭 取 任务 执行 。 


12.3.1 Java 线程 池 

使 用 Executors 来 创建 线程 池 。 

1. 创 建 单线 程 的 线程 池 。 

ExecutorService executorService = Executors.newSingleThreadExecutor (); 


等 价 于 


return new FinalizableDelegatedExecutorService 
(new ThreadPoolExecutor(1, 1, 
OL, TimeUnit.MILLISECONDS, 
new LinkedBlockingQueue<Runnable>()) ) 


2. 创 建 固定 数量 的 线程 池 。 
ExecutorService executorService = Executors.newFixedThreadPool (10); 


等 价 于 


return new ThreadPoolExecutor(nThreads, nThreads, 
OL, TimeUnit.MILLISECONDS, 
new LinkedBlockingQueue<Runnable>()); 


3. 创 建 可 缓存 的 线程 池 ， 初 始 大 小 为 0， 线 程 池 最 大 大 小 为 
Integer.MAX_VALUE 。 其 使 用 SynchronousQueue 队 列 ， 一 个 没有 数据 组 
冲 的 阻塞 队列 。 对 其 执行 put 操 作 后 必须 等 待 take 控 作 消 费 该 数据 ， 反 之 
亦 然 。 该 线程 池 不 限制 最 大 大 小 ， 如 果 线 程 池 有 空闲 线程 则 复 用 ， 否 则 
会 创建 一 个 新 线程 。 如 果 线 程 池 中 的 线程 空间 60 秒 ， 则 将 被 回收 。 该 线 
ee EU 请 确认 必要 后 再 使 用 该 线程 


ExecutorService executorService = Executors.newCachedThreadPool (); 


等 价 于 


new ThreadPoolExecutor(0, Integer.MAX VALUE, 
60L, TimeUnit.SECONDS, 
new SynchronousQueue<Runnable>() ) 


4. 支 持 延 迟 执行 的 线程 池 ， 其 使 用 DelayedWorkQueue 实 现任 务 延 迟 。 


ScheduledExecutorService scheduledExecutorService = 
Executors. newScheduledThreadPool (10); 


return new ScheduledThreadPoolExecutor(corePoolSize, Integer.MAX VALUE, 
0, NANOSECONDS, 
new DelayedWorkQueue()); 


5.work-stealing 22 fe TE , sk W Jf fT 9X A Runtime.getRuntime 
().availableProcessors() ° 


ExecutorService executorService = Executors.newWorkStealingPool (5); 
等 价 于 


return new ForkJoinPool(parallelism, 
ForkJoinPool.defaultForkJoinWorkerThreadFactory(), 
null, true); 


接 下 来 ， 我 们 来 看 一 下 ThreadPoolExecutor 配 置 。 


- corePoolSize: 核心 线程 池 大 小 ， 线 程 池 维 护 的 线程 最 小 大 小 ， 即 没有 
任务 处 理 情况 下 ， 线 程 池 可 以 有 多 个 空 几 线程 ， 类 似 于 DBCP 中 的 


minldle ° 


maximumPoolSize: 线程 池 最 大 大 小 ， 当 任务 数 非常 多 时 ， 线 程 池 可 创 
建 的 最 大 线程 数量 。 


-keepAliveTime: 线程 池 中 线程 的 最 大 空间 时 间 ， 存 活 时 间 超 过 该 时 间 
的 线程 会 被 回收 ， 线 程 池 会 一 直 缩 小 到 corePoolSize 大 小 。 


-workQueue: ”线程 池 使 用 的 任务 缓冲 队列 ， 包 括 有 界 阻 塞 数组 队列 
ArrayBlockingQueue ^ A 4/76 A EH 3& HE FS BA. 71] LinkedBlockingQueue ^ f 
^t 7k BH 3€ BA FI) PriorityBlockingQueue 、 无 缓冲 区 阻塞 队列 
SynchronousQueue。 有 界 阻 塞 队 列 须要 设置 合理 的 队列 大 小 。 


. threadFactory: 创建 线程 的 工厂 ， 我 们 可 以 设置 线程 的 名 字 、 是 否 是 
后 台 线 程 。 


: rejectedExecutionHandler: ” 当 绥 冲 队 列 满 后 的 拒绝 策略 ， 包 括 Abort 
(直接 抛 出 RejectedExecutionException) ` Discard (按照 LIFO 丢 弃 ) 
DiscardOldest (fZFRLRUEF) 、CallsRun (主线 程 执 行 ) ° 


Spring 也 提供 了 XML 标 签 用 来 方便 创建 线程 池 。 一 个 是 : 


<task:executor id-"asyncTaskExecutor" 
pool-size="S{executor.pool.size}" 
queue-capacity="S{executor.queue.capacity}" 
keep-alive="60"/> 

个 是 : 


男 一 个 是 


<task:scheduler id="scheduler" pool-size="10"/> 
6. 线 程 池 终止 


线程 池 不 再 使 用 后 记得 停止 掉 ， 可 以 调用 shutdown 以 确保 不 接受 新 任 
务 ， 并 等 待 线 程 池 中 任务 处 理 完成 后 再 退出 ， 或 调用 shutdownNow 清 除 未 
执行 任务 ， 并 用 Thread.interrupt 停 止 正在 执行 的 任务 。 然 后 调用 
awaitTermination 方 法 等 竺 终止 操作 执行 完成 ， 代 码 如 下 。 


Runtime.getRuntime().addShutdownHook(new Thread() { 
@Override 
public void run() { 
executorService. shutdown (); 
executorService.awaitTermination(30, TimeUnit.SECONDS) 


J):2 


7. 总 结 

根据 任务 类 型 是 IO 密集 型 还 是 CPU 密集 型 、CPU 核 数 ， 来 设置 合理 的 线 
a 、 Roo 、 拒绝 策略 ， 并 进行 压 测 和 不 断 调 优 来 决定 适合 自 
己 场 景 的 参数 。 


笔者 遇 到 过 因为 maximumPoolSize 设 置 的 过 大 导致 瞬间 线程 数 非常 多 。 还 
有 使 用 如 Executors.newFixedThreadPool 时 ， 因 没有 设置 队列 大 小 ， 默 认为 
IntegerMAX_VALUE ， 如 果 有 大 量 任务 被 缓存 到 LinkedBlockingQueue 中 
等 待 线程 执行 ， 则 会 出 现 GC 慢 等 问题 ， 造 成 系统 响应 慢 甚 至 OOM 。 
此 ， 在 使 用 线程 池 时 务必 须 设 置 池 大 小 、 队 列 大 小 并 设置 相应 的 拒绝 策 
Ms (RejectedExecutionHandler) 。 线 程 池 执 行情 况 下 无 法 捕获 堆栈 上 下 
文 ， 因 此 任务 要 记录 相关 参数 ， 以 方便 定位 提交 任务 的 源头 及 定位 引起 
问题 的 源头 。 


12.3.2 ”Tomcat 线 程 池 配 置 


以 Tomcat 8 为 例 配置 如 下 ， 配 置 方 式 一 。 


«Connector port="8080" acceptCount="100" maxConnections-"200" 
minSpareThreads -"10" maxThreads-"200"/» 


- acceptCount: 请 求 等 竺 队列 大 小 。 当 Tomcat 没 有 空闲 线程 处 理 连 接 请 
求 时 ， 新 来 的 连接 请 求 将 放 入 等 竺 队列 ， 默 认为 100。 当 队列 超过 
acceptCount 后 ， 新 连接 请 求 将 被 拒绝 。 


-maxConnections: Tomcat 能 处 理 的 最 大 并 发 连接 数 。 当 超过 后 LER 接 
收 连接 并 放 入 等 竺 队列 (acceptCount 控 制 ) ， 连 接 会 等 待 ， 不 能 被 处 
理 。BIO 默 认 是 maxThreads 数 量 。NIO 和 NIO2 默 认 是 10000，ARP 默 认 是 
8192 ° 


-minSpareThreads: 线程 池 最 小 线程 数 ， 默 认为 10。 该 配置 指定 线程 池 
可 以 维持 的 空闲 线程 数量 。 


-maxThreads: ”线程 池 最 大 线程 数 ， 默 认为 200。 当 线程 池 空 内 一 段 时 间 
后 会 释放 到 只 保留 minSpareThreads 个 线程 。 


这 


举例 ， 假 设 maxThreads=100，maxConnections=50，acceptCount=50， 假 设 
并 发 请 求 为 200， 则 有 50 个 线程 并 发 处 理 50 个 并 发 连接 ，50 个 连接 进入 等 
竺 队列 ， 剩 余 100 个 将 被 拒绝 。 也 就 是 说 Tomcat 最 大 并 发 线程 数 是 由 
maxThreads 和 maxConnections 中 最 小 的 一 个 决定 。BIO 场 景 下 
maxConnections 和 maxThreads 是 一 样 的 ， 当 我 们 需要 长 连接 场景 时 ， 应 使 
用 NIO 模 式 ， 并 发 连接 数 是 大 于 线程 数 的 。 


配置 方式 二 。 


<Executor name="tomcatThreadPool" nanePrefix-"catalina-exec-" deamon- "true" 
minSpareThreads-"25" maxThreads-"200" maxIdleTime-"60000" 
maxQueueSize- "Integer.MAX VALUE" 
prestartminSpareThreads-"false"/» 

«Connector port="8080" executor="tomcatThreadPool" 
executorTerminationTimeoutMillis ="5000"/> 


此 处 我 们 使 用 了 org.apache.catalina.Executor 实 现 ， 其 表示 一 个 可 在 多 个 
Connector 间 共享 的 线程 池 ， 而 且 有 更 丰富 的 配置 。 


. namePrefix: ”创建 的 Tomcat 线 程 名 字 的 前 级。 


:deamon: 是 否 守护 线程 运行 ， 默 认为 true。 
-minSpareThreads: 线程 池 最 小 线程 数 ， 默 认为 25。 
-maxThreads: 线程 池 最 大 线程 数 ， 默 认为 200。 


-maxIdleTime: 衬 亲 线程 池 的 存活 时 间 ， 默 认为 60s。 当 线程 空 有 超过 该 
时 间 后 ， 线 程 将 被 回收 。 


-maxQueueSize: 任务 队列 最 大 大 小 ， 默 认为 ntegerMAX_VALUE， 建 
议 改 小 。 可 以 认为 是 maxConnections。 


* prestartminSpareThreads : 是 否 在 Tomcat 启 动 时 就 创建 
minSpareThreads 个 线程 放 入 线程 池 ， 默 认为 false ° 


- executorTerminationTimeoutMillis: 在 停止 Executor 时 ， 等 竺 请求 处 理 


线程 终止 的 超时 时 间 。 


最 后 ， 要 根据 业务 场景 和 压 测 来 配置 合理 的 线程 池 大 小 ， 配 置 太 大 的 线 
程 池 在 并 发 量 较 大 的 情况 下 会 引起 请 求 处 理 不 过 来 导致 啊 应 慢 ， 其 至 造 
成 Tomcat 伪 死 。 


在 本 书 出 版 上 时， Docker 4 a 中 使 Hj Runtime.getRuntime 
().availableProcessors() 获 取 到 的 是 物理 机 核 数 ， 而 不 是 容器 实际 使 用 的 核 
数 ， 这 将 对 性 能 造成 极 大 影响 。 所 有 用 到 该 参数 的 地 方 都 要 记得 调整 ， 
如 CMS 垃圾 回收 参数 : -XX:ParallelGCThreads 和 -XX:ConcGCThreads， 可 
扫 二 维 码 参考 《使 用 Docker 容 絮 时 不 要 忘记 进行 GC 参数 审查 》。 


在 做 电 商 系统 时 ， 首 页 、 活 动 页 、 商 品 详情 页 等 系统 承载 了 网 站 的 大 部 
分 流量 ， 而 这 些 系统 的 主要 职责 包括 聚合 数据 拼装 模板 、 热 点 统计 、 绥 
存 、 下 游 功 能 降级 开关 、 托 底数 据 等 。 其 中 聚合 数据 需要 调用 多 个 其 他 
服务 获取 数据 、 拼 装 数 据 /模板 ， 然 后 返回 给 前 端 ， 聚 合 数据 来 源 主要 有 
依赖 系统 /服务 、 绥 存 、 数 据 库 等 。 而 系统 之 间 的 调用 可 以 通过 如 HTTP 接 
口 调用 (如 HttpClient) 、SOA 服 务 调用 (如 dubbo、thrift) 等 实现 。 


在 Java 中 ， 如 使 用 Tomcat， 一 个 请 求 会 分 配 一 个 线程 进行 请 求 处 理 ， 该 线 
程 负责 获取 数据 、 拼 装 数 据 或 模板 ， 然 后 返回 给 前 端 。 在 同步 调用 获取 
数据 接口 的 情况 下 (等 待 依赖 系统 返回 数据 ， 整 个 线程 是 一 直 被 占用 
并 阻塞 的 。 如 果 有 大 量 的 这 种 请 求 ， 则 每 个 请 求 占用 一 个 线程 ， 但 线程 
一 直 处 于 阻塞 ， 降 低 了 系统 的 吞吐 量 ， 这 将 导致 应 用 的 吞吐 量 下 降 。 我 
们 希望， 在 调用 依赖 的 服务 响应 比较 慢 时 ， 应 该 让 出 线程 和 CPU 来 处 理 
下 一 个 请 求 ， 当 依赖 的 服务 返回 后 再 分 配 相 应 的 线程 来 继续 处 理 。 而 这 
应 该 有 更 好 的 解决 方案 : 异步 / 协 程 。 而 Java 是 不 支持 协 程 的 (虽然 有 些 
Java 框 架 号 称 支 持 ， 但 还 是 高 层 API 的 封装 ) ， 因 此 ， 在 Java 中 我 们 可 以 
使 用 异步 来 提升 厨 吐 量 。 目 前 大 部 分 Java 开 源 框架 (HttpAsyncClient ^ 
Dubbo、Thrift 等 ) 都 支持 。 


男 外 ， 应 用 中 一 个 服务 可 能 会 调用 多 个 依赖 服务 来 处 理 业务 ， 而 这 些 依 
赖 服 务 是 可 以 同时 调用 的 。 如 采 顺 序 调 用 的 话 需要 耗 时 100ms， 而 并 发 调 
用 只 需要 50ms， 那 么 可 以 使 用 Java 并 发 机 制 来 并 发 调用 依赖 服务 ， 从 而 
降低 该 服务 的 啊 应 时 间 。 


库存 


TE 商品 详情 页 
一 请 求 -| 促销 
ias 服务 


价格 


在 开发 应 用 系统 过 程 中 ， 通 过 异步 并 发 并 不 能 使 响应 变 得 更 快 ， 更 多 是 
为 了 提升 吞吐 量 、 对 请 求 更 细 粒 度 控制 ， 或 是 通过 多 依赖 服务 并 发 调用 
降低 服务 响应 时 间 。 当 一 个 线程 在 处 理 任务 时 ， 通 过 Fork 多 个 线程 来 处 
理 任 务 并 等 待 这 些 线程 的 处 理 结果 ， 这 种 应 用 并 不 是 真正 的 异步 。 异 步 
是 针对 CPU 和 IO 的 ， 当 IO 没有 就 绪 时 要 让 出 CPU 来 处 理 其 他 任务 ， 这 才 
是 异步 。 本 文 不 会 介绍 异步 并 发 实现 原理 ， 主 要 介绍 在 Java 应 用 中 如 何 运 
用 这 些 技术 ， 而 且 大 多 数 场景 并 不 是 真正 的 异步 化 ， 在 Java 中 真正 实现 异 
步 化 是 非常 困难 的 事情 ， 如 MySQL JDBC 驱 动 等 很 多 都 是 BIO 设 计 ， 大 多 
数 情况 下 说 的 异步 并 发 是 通过 线程 池 模 拟 实 现 。 


13.1 同步 阻塞 调用 
即 串 行 调用 ， 啊 应 时 间 为 所 有 依赖 服务 的 啊 应 时 间 总 和 。 


public class Test { 

public static void main(String[] args) throws Exception { 
RpcService rpcService - new RpcService(); 
HttpService httpService = new HttpService(); 
// 耗 时 为 10ms 
Map<String, String» resultl = rpcService.getRpcResult(); 
// 耗 时 为 20ms 
Integer result2 = httpService.getHttpResult(); 
// 总 耗 时 为 30ms 

} 

static class RpcService { 

Map<String, String> getRpcResult() throws Exception { 
// 调 用 远程 方法 (远程 方法 耗 时 约 10ms， 可 以 使 用 Thread.sleep 模拟 ) 


} 
} 


static class HttpService { 


Integer getHttpResult() throws Exception { 
// 调 用 远程 方法 (远程 方法 耗 时 约 20ms， 可 以 使 用 Thread.sleep 模拟 ) 
Thread.sleep(20); 
return 0; 


13.2 异步 Future 


线程 池 配 合 Future 实 现 ， 但 是 阻塞 主 请 求 线 程 ， 高 并 发 时 依然 会 造成 线 和 
数 过 多 、CPU 上 下 文 切换 。 通 过 Future 可 以 并 发 发 出 N 个 请求 ， 然 后 等 待 
最 慢 的 一 个 返回 ， 总 啊 应 时 间 为 最 慢 的 一 个 请 求 返 回 的 用 时 。 如 下 请 求 
如 果 并 发 访问 ， 则 响应 可 以 在 30ms 后 返回 。 


rpc service1 
20ms 


rpc service2 
10ms 


rpc service3 | 


30ms 


public class Test { 
final static ExecutorService executor - 
Executors.newFixedThreadPool (2); 
public static void main(String[] args) { 
RpcService rpcService = new RpcService(); 
HttpService httpService = new HttpService(); 
Future<Map<String, String>> futurel = null; 
Future<Integer> future2 = null; 


try { 
futurel = executor.submit(() -> rpcService.getRpcResult()); 
future2 = emgcutor.submit(() -> httpService.getHttpResult()); 
// 耗 时 为 10ms 


Map<String, String» resultl = 
futurel.get (300, TimeUnit.MILLISECONDS) ; 


// 耗 时 为 20ms 
Integer result2 = future2.get(300, TimeUnit.MILLISECONDS); 


// 总 耗 时 为 20ms 
) catch (Exception e) { 
if (futurel !- null) { 
futurel.cancel(true); 
) 
if (future2 !- null) { 
future2.cancel(true); 


} 


throw new RuntimeException (e); 


} 
static class RpcService { 
Map<String, String> getRpcResult() throws Exception { 
// 调 用 远程 方法 (远程 方法 耗 时 约 10ms， 可 以 使 用 Thread.sleep 模拟 ) 
} 
} 
static class HttpService { 
Integer getHttpResult() throws Exception { 
// 调 用 远程 方法 (远程 方法 耗 时 约 20ms， 可 以 使 用 Thread.sleep 模拟 ) 


} 


} 


13.3 Callback 


通过 回调 机 制 实现 ， 即 首先 发 出 网 络 请 求 ， 当 网 络 返回 时 回调 相关 方 
法 ， 如 HttpAsyncClien 使 用 基于 NIO 的 异步 IO 模型 实现 ， 它 实现 了 Reactor 
模式 ， 握 弃 阻 塞 1/O 模 型 one thread per connection， 采 用 线程 池 分 发 事件 通 
知 ， 从 而 有 效 文 撑 大 量 并 发 连接 。 这 种 机 制 并 不 能 提升 性 能 ， 而 是 为 了 
文 撑 大 量 并 发 连接 或 者 提升 吞吐 量 。 


public class AsyncTest { 
public static HttpAsyncClient httpAsyncClient; 
public static CompletableFuture<String> getHttpData (String url) { 
CompletableFuture asyncFuture = new CompletableFuture(); 


HttpAsyncRequestProducer producer - 
HttpAsyncMethods.create(new HttpPost(url)); 


BasicAsyncResponseConsumer consumer - 


new BasicAsyncResponseConsumer(); 


FutureCallback callback = new FutureCallback<HttpResponse>() { 
public void completed(HttpResponse response) { 
asyncFuture.complete (response) ; 
} 
public void failed(Exception e) { 
asyncFuture.completeExceptionally (e); 
) 
public void cancelled() { 
asyncFuture.cancel (true); 
} 
}; 


httpAsyncClient.execute (producer, consumer, callback); 
return asyncFuture; 


) 


public static void main(String[] args) throws Exception ( 
CompletableFuture<String> future = 


AsyncTest.getHttpData ("http://www.jd.com") ; 
String result = future.get(); 


这 种 异步 实现 可 以 配合 CompletableFuture 实 现 半 异步 。 


13.4 ”异步 编排 CompletableFuture 


JDK 8 CompletableFuture 提 供 了 新 的 异步 编程 思路 ， 可 以 对 多 个 异步 处 理 
进行 编排 ,实现 更 复杂 的 异步 处 理 。 其 内 部 使 用 ForkJoinPool 实 现 异步 处 
理 。 使 用 CompletableFuture 可 以 把 回调 方式 的 实现 转变 为 同步 调用 实现 。 
CompletableFuture 提 供 了 50 多 个 API， 可 以 满足 各 种 所 需 场 景 的 异步 处 理 
编排 ， 在 此 列举 三 个 场景 。 


ree ， 然 后 对 结 采 合并 处 理 ， 不 阻塞 主线 


Service1 


Service2 合并 结果 


Service2 


public static void test1() throws Exception { 
MyService service - new MyService(); 
CompletableFuture<String> futurel = 
service.getHttpData ("http:// www.jd.com") ; 
CompletableFuture<String> future2 = 
service.getHttpData ("http:// www.jd.com") ; 
CompletableFuture<String> future3 = 
service.getHttpData ("http: //www.jd.com") ; 


CompletableFuture.allOf(futurel, future2, future3) 
.thenApplyAsync((Void) -> { 
// 蜡 步 处 理 futurel future2 future3 结果 
}) .exceptionally(e -> { 
/ /处理 异 党 
DE 


如 上 方式 直接 通过 thenApplyAsync 异 步 处 理 future1~3 的 结果 ， 不 阻塞 主线 
程 ， 内 部 使 用 ForkJoinPool 线 程 池 实 现 。 也 可 以 通过 返回 一 个 新 的 
CompletableFuture 来 同步 处 理 结果 ， 即 阻塞 主线 程 。 


CompletableFuture<List> future4 = CompletableFuture 
.allOf(futurel, future2, future3) 
.thenApply((Void) -> ( 
return Lists.newArrayList( 
futurel.get(), future2.get(), future3.get()) 
}) .exceptionally(e -> { 
// 处 理 异 常 
} ) ; 


场景 二 是 两 个 服务 并 发 调用 ， 然 后 消费 结果 ， 不 阻塞 主线 程 。 


public static void test2() throws Exception { 
MyService service - new MyService(); 


CompletableFuture<String> futurel = 


service.getHttpData ("http:// www.jd.com") ; 
CompletableFuture<String> future2 = 
service.getHttpData ("http:// www.jd.com") ; 


futurel.thenAcceptBothAsync( 
future2, (futurelResult, future2Result) -> { 
// 异 步 处 理 结果 
}) .exceptionally(e -> { 
// 异 常 处 理 
}); 


场景 三 征服 务 1 执行 完成 后 ， 接 着 并 发 执行 服务 2 和 服务 3， 然 后 消费 相关 
结 采 ， 不 阻塞 主线 程 。 


Service2 


Service1 消费 结果 


Service3 


public static void test3() throws Exception { 
MyService service - new MyService(); 


CompletableFuture<String> futurel = 
service.getHttpData("http:// servicel") ; 
CompletableFuture<String> future2 = 
futurel.thenApplyAsync((v) -> { 
return "result from service2"; 


} ) 
CompletableFuture<String> future3 = 


service.getHttpData("http:// service3") ; 
future2.thenCombineAsync(future3, (f2Result, f3Result) -> { 
// 处 理 业务 
)).exceptionally(e -> { 
// 处 理 异 常 
)); 


135 “异步 web 服 务实 现 


借助 Servlet 3、CompletableFuture 实 现 异 步 Web 服 务 。 如 下 是 整个 处 理 流 
程 。 


清 求 开始 


提交 到 业务 处 理 线 业务 处 理 一 同步 调用 (调用 
Ritt 数据 库 、 集 中 缓存 Redis) 


CompletableFuture 是 一 个 包括 所 有 结 
果 处 理 基数 和 即将 要 返回 的 结果 值 
(直到 有 结果 时 才 触 发 处 理 函 数 ) : 
servlet3 会 持 有 请 求 上 下 文 与 
CompletableFuture 做 到 全 蜡 步 非 阻塞 


注意 :定时 清理 
CompletableFuture 的 超时 情 
况 ， 所 以 要 维护 正在 等 待 回 


业务 处 理 - 异 步调 用 《分 别 
异步 调用 远程 服务 
httpAsyncClient, thrift) 


调 的 Future 


编排 CompletableFuture 处 
理 结 果 数 据 (结果 返 回 时 
触发 


返回 CompletableFuture 


Servlet 容 器 接收 到 请 求 之 后 ，Tomcat 需 要 先 解析 请 求 体 ， 然 后 通过 异步 
Servlet 将 请 求 交 给 异步 线程 池 来 完成 业务 处 理 ，Tomcat 线 程 释放 回 容器 。 
通过 异步 机 制 可 以 提升 Tomcat 容 器 的 否 吐 量 。 


public void submitFuture(finalHttpServletRequest req, final Callable 


«CompletableFuture» task) throwsException( 
final String uri = req.getRequestURI(); 
final Map<String, String[]> params = req.getParameterMap(); 
final AsyncContext asyncContext = req.startAsync(); 
asyncContext.getRequest().setAttribute("uri", uri); 
asyncContext.getRequest().setAttribute ("params", params); 
asyncContext.setTimeout (asyncTimeoutInSeconds * 1000); 
if(asyncListener != null) { 
asyncContext.addListener (asyncListener) ; 
} 
CompletableFuture future = task.call(); 
future.thenAccept (result -> { 
HttpServletResponse resp = 
(HttpServletResponse)asyncContext.getResponse(); 
try { 
if(result instanceof String) ( 
byte[] bytes = result.getBytes ("GBK") ; 
resp.setContentType ("text/html;charset-gbk"); 
resp.setContentLength (bytes.length); 
resp.getOutputStream().write (bytes); 
) else { 
write (resp, JSONUtils.toJSON (result) ); 
} 
} catch (Throwable e) { 
resp.setStatus ( 
HttpServletResponse.SC INTERNAL SERVER ERROR); 
// 程 序 内 部 错误 
try { 
LOG.error("get infoerror, uri: {}, params : {}", 
uri, JSONUtils.toJSON (params), e); 
} catch (Exception ex) { 
} 
} finally { 
asyncContext.complete(); 
) 
}) .exceptionally(e -> { 
asyncContext.complete(); 
return null; 
); 


13.6 ”请 求 缓存 


在 一 个 查询 库存 的 服务 中 ， 因 为 一 些 特殊 原因 对 同一 个 商品 查询 了 多 
次 ， 即 一 次 用 户 请 求 需要 重复 调用 多 次 商品 接口 。 我 们 一 般 的 做 法 是 将 
GetProductService 包 闭 一 层 JVM 绥 存 ， 不 过 ， 使 用 Hystrix 后 ， 我 们 还 有 另 
一 种 请 求 级 别 的 缓存 实现 。 


QueryStock 
查询 商品 GetProductService 
查询 库存 查询 商品 
再 次 查询 商品 


GetProductServiceCommand 实现 代码 如 下 。 


public class GetProductServiceCommand extends HystrixCommand<String> { 
private ProductService productService; 
private Long id; 
public GetProductServiceCommand ( 
ProductService productService, Long id) { 
super (setter ()); 
this.id = id; 
this.productService = productService; 


@Override 
protected String run() throws Exception { 
return productService.getProduct (id) ; 


} 


@Override 
protected String getCacheKey() { 
return "product-" + id; 
} 
} 


此 处 需要 实现 getCacheKey 方 法 ， 指 定 缓存 key。 


需要 使 用 withRequestCacheEnabled(true) 配 置 开局 请 求 缓存 支持 。 


HystrixCommandProperties.Setter commandProperties = 
HystrixCommandProperties.Setter() 
.withExecutionIsolationStrategy (HystrixCommandProperties.Execut 
ionIsolationStrategy. THREAD) 
.withRequestCacheEnabled (true) // 默 认 true 


业务 代码 调用 实现 如 下 。 


HystrixRequestContext context = HystrixRequestContext. initializeContext(); 
try { 
ProductService productService - new ProductService(); 
GetProductServiceCommand commandl - 
new GetProductServiceCommand (productService, 11); 
GetProductServiceCommand command2 - 
new GetProductServiceCommand (productService, 11); 
commandl.execute(); 
command2.execute(); 
Assert.assertFalse(commandl.isResponseFromCache()); 
Assert.assertTrue(command2.isResponseFromCache()); 
) finally { 
context.shutdown(); 


) 


Hystrix 使 用 了 ThreadLocal HystrixRequestContext 实 现 ， 并 在 异步 线程 执行 
之 前 注入 ThreadLocal HystrixRequestContext 实 现 多 个 线程 共享 ， 从 而 实现 
请 求 级 别 的 响应 缓存 。 


下 面 看 一 下 如 何 用 CompletableFuture 实 现 批量 查询 。 


我 们 有 个 服务 需要 多 次 查询 价格 ， 而 价格 服务 提供 了 单个 查询 和 批量 查 
询 接口 。 一 种 方式 是 我 们 在 客户 端 多 线程 查询 ， 然 后 聚合 。 另 一 种 方式 
是 调用 批量 查询 接口 “一 些 服务 器 端 实现 其 实 是 串 行 的 ， 这 种 情况 建议 
使 用 客户 端 多 线程 查询 ， 而 不 是 服务 器 端 提供 的 支持 ) 。 在 调用 批量 接 
口 时 ， 我 们 需要 限制 每 次 批量 的 大 小 ， 从 而 减少 阻塞 时 间 。 


**Service 
查询 价格 PriceService 
S ARE 查询 价格 
查询 价格 


使 用 CompletableFuture 实 现 客户 端 多 线程 批量 查询 。 


List«CompletableFuture«Double»» futures = Lists.newArrayList(); 
for(Long id: ids) { 
futures.add(CompletableFuture.supplyAsync( 
() -> (return priceService. getPrice(id);))); 
) 
CompletableFuture.allOf( 
futures.toArray (new CompletableFuture[0])).get(); 


因为 我 们 知道 价格 有 批量 接口 ， 也 可 以 在 客户 端 调用 批量 接口 实现 。 但 
征 ， 我 们 不 能 一 次 批量 查询 太 多 价格 数据 ， 服 务 顺 端 限定 我 们 每 次 最 多 
查询 10 个 。 因 此 ， 我 们 需要 对 id 进行 分 区 ， 以 实现 批量 查询 。 


List<CompletableFuture<List<Double>>> futures = Lists.newArrayList(); 
List<List<Long>> pages = Lists.partition(ids, 10); 


for(List«Long» page : pages) { 
futures.add(CompletableFuture.supplyAsync(() -> { 
return priceService.getPrices (page); 


9); 


) 
CompletableFuture.allOf( 
futures.toArray (new CompletableFuture[0])).get(); 


13.7 请求 合 并 


CompletableFuture 必 须 提 前 构造 好 批量 查询 ， 而 Hystrix 文 持 将 多 个 单个 请 
求 转换 为 单个 批量 请 求 ， 即 可 以 按照 单个 命令 来 请 求 。 但 是 ， 实 际 是 以 
批量 请 求 模 式 执行 。 


Hystrix 请 求 合 并 业务 代码 如 下 。 


HystrixRequestContext context - 
HystrixRequestContext.initializeContext(); 
try ( 
PriceService priceService - new PriceService(); 
GetPriceServiceCommand commandl = 
new GetPriceServiceCommand (priceService, 1L); 
GetPriceServiceCommand command2 - 
new GetPriceServiceCommand (priceService, 21); 


GetPriceServiceCommand command3 = 


new GetPriceServiceCommand (priceService, 3L); 


Future«Double» fl = commandl.queue(); 
Future<Double> f2 = command2.queue(); 
Future<Double> f3 -command3.queue(); 


r 


fl.get() 

f2.get(); 

f3.get (); 
) finally ( 
context.shutdown(); 


可 以 看 到 ， 业 务 代码 还 是 单个 价格 查询 。Hystrix 内 部 会 将 多 个 查询 进行 
E 此 处 需要 先 使 用 queue 而 不 能 直接 使 用 execute 方 法 调 


**Service 


a GetPriceServiceCommand 
查询 价格 


查询 价格 L oa GetPriceServiceCommand BatchPriceCommand 


hes AN. 
查询 价格 M> GetpriceServiceCommand 


当 我 们 调用 GetPriceServiceCommand 时 ， 最 终 会 将 请 求 合 并 ， 然 后 交 由 
BatchPriceCommand 执 行 批 量 查询 。 


GetPriceServiceCommand 实 现 


public class GetPriceServiceCommand 
extends HystrixCollapser <List<Double>, Double, Long» { 
private PriceService priceService; 
private Long id; 
public GetPriceServiceCommand(PriceService priceService, Long id) { 
super (setter()); 
this.priceService - priceService; 
this.id - id; 


private static HystrixCollapser.Setter setter() ( 
return HystrixCollapser.Setter 
.withCollapserKey(HystrixCollapserKey.Factory.asKey("pri 
ce")) 
.andCollapserPropertiesDefaults (HystrixCollapserProperti 


es.Setter() 
.withMaxRequestsInBatch (2) 
.withTimerDelayInMilliseconds (5) 
.withRequestCacheEnabled (true) ) 
.andScope (Scope. REQUEST) ; 


@Override 
public Long getRequestArgument() { 
return id; 


} 


@Override 
protected HystrixCommand<List<Double>> createCommand (Collection 


«CollapsedRequest«Double, Long>> requests) { 
return new BatchPriceCommand (priceService, requests); 


@Override 
protected void mapResponseToRequests (List<Double> batchResponse, 
Collection<CollapsedRequest<Double, Long>> requests) { 
final AtomicInteger count = new AtomicInteger (0); 
requests.forEach((request) -> { 
request.setResponse ( 
batchResponse.get (count.getAndIncrement())); 


DE 


HystrixCollapser.Setter 配 置 


- collapserKey : 配置 全 局 唯一 标识 服务 合并 的 名 称 ， 类 似 
HystrixCommandKey。 如果 不配 置 ， 则 默认 是 简单 类 名 ， 通 过 该 名 称 进行 
请 求 合并 。 


- collapserPropertiesDefaults : maxRequestsInBatch 配 置 每 个 请 求 合并 人 允 
许 的 最 大 请 求 数 ， 如 果 请 求 多 于 此 配置 会 分 多 批 次 执行 ， 默 认为 
Integer. MAX, VALUE 。timerDelayInMilliseconds 配 置 在 批 处 理 执行 之 前 的 
等 待 超 时 时 间 ， 默 认为 10ms。requestCacheEnabled 如 果 跨 多 请 求 进 行 请 求 
合并 ， 则 必须 开启， 开局 后 可 以 消除 重复 请 求 ， 默 认为 true。 


‘scope: 请 求 合 并 范围 ， 默 认为 Scope.REQUEST， 即 当前 请 求 上 下 文 。 
如 果 配 置 为 Scope.GLOBAL， 则 表示 全 局 ， 即 可 以 跨越 多 个 请 求 上 下 文 进 
行 请 求 合 并 。 如 果 需 要 GLOBAL ， 则 记得 开局 requestCacheEnabled。 建 议 
S00 如 果 非 要 使 用 GLOBAL ， 那 么 请 给 出 合理 的 理 


timerDelayInMilliseconds 是 请 求 合 并 时 执行 的 延迟 时 间 ， 如 果 请 求 合并 数 
量 正好 等 于 maxRequestsImnBatch， 那 么 就 不 需要 等 等 而 立即 执行 。 但 是 ， 
如 果 请 求 数量 <maxRequestsInBatch， 那 么 请 求 会 在 该 超时 时 间 后 才 执 


[je 其 使 用 2E 程 池 Hy scheduleAtFixedRate(r, 
listener.getInterval TimeInMilliseconds(), listener.getInterval TimeIn 


Milliseconds(), TimeUnit. MILLISECONDS) $i o 
HystrixCollapser 的 实现 方法 如 下 。 


 getRequestArgument : 返回 请 求 参 数 ， 如 果 有 多 个 参数 需要 包装 为 一 
个 ， 参 数 会 被 封装 为 CollapsedRequest。 


-createCommand : 创建 可 批量 执行 的 Command， 当 HystrixCollapser 对 请 
求 进行 合并 后 达到 maxRequestsInBatch 时 或 timerDelayInMilliseconds 超 时 
后 ， 就 会 创建 批 处 理 命 令 ， 如 示例 中 的 BatchPriceCommand ° 


: mapResponseToRequests : 将 执行 结果 映射 到 请 求 中 ， 从 而 单个 请 求 束 
可 以 获得 结果 了 。 


` shardRequests : 如 果 想 把 不 同 的 请 求 分 到 不 同 的 分 组 进行 请 求 合 并 ， 
可 以 使 用 该 命令 ， 如 HashTag 应 用 。 比 如 一 个 商品 有 商品 基本 信息 
(p:id:)、 商 品 介绍 (d:id:)、 颜 色 尺 码 (c:id:) 等 标签 ， 我 们 存储 时 如 不 采用 
HashTag 将 会 导致 这 些 数据 不 会 存储 到 一 个 分 片 ， 而 是 分 散 到 多 个 分 片 。 
这 样 获取 时 需要 从 多 个 分 片 获取 数据 进行 合并 ， 无 法 进行 mget。 如 果 有 
了 HashTag， 那 么 可 以 使 用 “::” 中 间 的 数据 做 分 片 逻 辑 ， 这 样 id 一 样 的 将 会 
分 到 一 个 分 片 。shardRequests 可 以 按照 HashTag 类 似 机 制 实现 。 


BatchPriceCommand 实 现 


class BatchPriceCommand extends HystrixCommand<List<Double>> { 
private PriceService priceService; 
private Collection<CollapsedRequest<Double, 
public BatchPriceCommand (PriceService priceService, Collection< 
CollapsedRequest«Double, Long>> requests) { 
super(setter()); 
this.priceService - priceService; 
this.requests - requests; 


Long»» requests; 


) 


private static Setter setter() { 
return Setter.withGroupKey ( 


HystrixCommandGroupkey.Factory.asKey ("price") ) ; 


} 


@Override 
protected List<Double> run() throws Exception { 
List<Long> ids = requests.stream() 
.map(req -> (return req.getArgument ();]) 
.collect(Collectors.toList()); 
return priceService.getPrices (ids); 


询 接口 ， 从 而 将 多 个 单 次 查询 合并 为 一 个 批量 查询 。 


14 ”如 何 扩容 


对 于 一 个 发 展 初期 的 系统 来 说 ， 不 太 确 定 商业 模型 到 底 行 不 行 ， ayes 


办 法 是 按照 最 小 可 行 产品 方法 进行 产品 验证 ， 因此 ， 刚 开始 的 功能 会 比 
较 少 ， 是 一 个 大 的 单 体 应 用 ， 一般 按照 三 层 架 构 进 行 设计 开发 ， 使 用 单 


数据 库 ， 绥 存 也 是 可 选 组 件 ， 而 应 用 系统 和 数据 库 也 很 可 能 部 署 在 同一 
台 物 理 机 上 ， 如 下 图 所 示 。 


** 在 线 交易 系统 


WEB 层 
首页 || 列表 页 | | 单 品 页 
购物 车 | | 结算 页 || nnm 
服务 层 
| 商品 | | 购物 车 || 结算 
订单 支付 || eee 
数据 访问 层 
商品 购物 车 订单 
RA Le I e 
数据 库 缓存 


对 于 这 样 一 个 系统 ， 随 着 产品 使 用 的 用 户 越 来 越 多 ， 网 站 的 流量 会 增 
加 ， 最 终 单 台 服务 右 无 法 处 理 那 么 大 的 流量 ， 此 时 束 需 要 用 分 而 治之 的 
思想 来 解决 问题 。 


一 步 古 尝试 通过 简单 扩容 来 解决 。 


二 步 ， 如 采 人 简单 扩容 搞 不 定 ， 束 需 要 水 平 拆 分 和 垂直 拆 分 数据 /应 用 来 
升 系统 的 伸缩 性 ， 即 通过 扩容 提升 系统 负载 能 力 。 
Z 


三 步 ， 如 果 通 过 水 平 拆 分 / 牌 直 拆 分 还 是 摘 不 定 ， 那 就 需要 根据 现 有 系 
统 特性 ， 从 架构 层面 进行 重 构 甚至 是 重新 设计 ， 即 推倒 重 来 。 


对 于 系统 设计 ， 理 想 的 情况 下 应 支持 线性 扩容 和 弹性 扩容 ， 即 在 系统 瓶 
颈 时 ， 只 需要 增加 机 器 就 可 以 解决 系统 瓶颈 ， 如 降低 延迟 提升 吞吐 量 ， 
从 而 实现 扩容 需求 。 


如 果 你 想 扩容 ， 则 支持 水 平 /垂直 伸缩 是 前 提 “。 在 进行 拆 分 时 ， 一 定 要 清 

楚 知 道 自己 的 目的 是 什么 ， 拆 分 后 带 来 的 问题 如 何 解 决 ， 拆 分 后 如 果 没 

有 得 到 任何 收益 就 不 要 为 了 拆 而 拆 ， 即 不 要 过 度 拆 分 ， 要 适合 自己 的 业 

eee 
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141 单 体 应 用 垂直 扩容 
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有 些 时候 ， 如 果 能 通过 硬件 快速 解决 ， 而 且 成 本 不 高 ， 应 该 首先 通过 硬 
件 扩容 来 解决 问题 。 硬 件 扩容 包括 升级 现 有 服务 器 ， 比 如 CPU 由 原来 的 
32 核 升级 到 64 核 ;内存 从 64GB 升 级 到 256GB 〈 有 的 缓存 服务 器 CPU 利用 
率 很 低 ， 但 是 内 存 不 够 用 ， 就 通过 扩容 内 存 来 提升 单机 容量 ) ; 人 磁盘 扩 
容 ， 比 如 系统 有 大 量 的 随机 读 写 ， 因 此 把 HDD 换 成 SSD， 还 有 将 原来 单 
机 1TB 扩 容 为 2TB; 原来 硬盘 做 了 RAID 10， 现 在 直接 拆 为 裸 盘 使 用 ， 通 
过 架构 层面 提升 数据 可 靠 性 。 此 外 ， 核 心 数据 库 可 以 使 用 PCIe SSD BK 
NVMe SSD， 千 兆 网 卡 可 以 升级 为 万 兆 网 卡 。 不 管 怎 么 扩容 ， 单 机 总 会 是 
瓶 贷 ， 而 分 布 式 技术 是 提升 系统 扩容 能 力 的 更 好 方法 。 


14.2 单 体 应 用 水 平 扩 容 


单 体系 统 水 平 扩容 十 通过 部 署 更 多 的 镜像 来 实现 的 。 如 下 图 所 示 ， 原 来 

通过 一 个 系统 实例 对 外 提供 服务 ， 通 过 扩容 到 更 多 实例 后 ， 用 户 访 问 时 

D TRU 口 ， 应 该 提供 统一 入 口 ， 此 时 就 需要 负载 均衡 
| 来 实现 。 


负载 均衡 器 


£— —3— —3 


** 在 线 交 易 系 统 | | ** 在 线 交 易 系 统 | | eee 
RI ik 
T : 


主 数据 库 <n 从 数据 库 | 


pum Bis QUE AT BUENAS, Wire SE A BY E ST Ji A T 
T (0) 


RATE SH HSE REA, MIER RT OE E E MA IR E R RA 
ee ee 写 数据 时 写 到 主 数据 库 ， 读 数据 时 读 取 
车 。 


经 过 单 体 应 用 的 垂直 /水 平 扩容 ， 如 果 系 统 还 古 有 瓶 贷 ， 则 此 时 只 有 通过 
拆 分 应 用 来 解决 。 


14.3 MASS 


对 于 单 体 应 用 来 说 ， 随 着 业务 量 的 增加 ， 一 个 大 系统 就 会 有 很 多 人 维 
护 ， 这 殊 造 成 修改 代码 会 出 现 冲 突 ， 上 线 必须 大 家 一 起 上 线 ， 而 且 风 险 
较 大 ， 导 致 需求 实现 速度 缓慢 。 因 此 单 体 应 用 发 展 到 一 定 地 步 时 ， 会 按 
照 业 务 进行 拆 分 。 


www.***.com trade.***.com 
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服务 导 服务 层 
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数据 访问 层 数据 访问 层 
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如 上 图 所 示 ， 我 们 按照 业务 将 一 个 大 系统 拆 分 为 多 个 子 系统 ， 比 如 网 站 
系统 和 交易 系统 。 拆 分 时 要 进行 业务 代码 解 类 ， 将 功能 分 离 到 不 同系 统 
上 。 拆 分 后 系统 之 间 是 物理 隔离 的 ， 应 用 层面 原来 是 直接 进程 内 方法 调 
用 ， 现 在 需要 改 成 远程 方法 调用 ， 比 如 通过 WebService、RMI 等 。 


通过 拆 分 ， 可 以 由 两 个 团队 分 别 维护 网 站 和 交易 系统 ， 相 互 之 间 的 更 新 
古 不 冲突 的 。 但 是 目前 也 存在 一 些 问题 ， 比 如 ， 我 们 使 用 RMI 机 制 ， 需 
要 使 用 方 维护 一 个 服务 方 IP 列 表 。 因 此 下 一 个 方向 是 SOA 化 ， 如 下 图 所 
ZR ° 
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随 着 系统 流量 越 来 越 大 ， 我 们 会 继续 在 业务 拆 分 基础 上 ， 按 照 功 能 域 拆 
分 为 前 端 web 系 统 和 基础 服务 。 因 为 随 着 业务 的 发 展 ， 流 量 越 来 越 大 ， 解 
决 方案 越 来 越 复 杂 。 像 商品 、 购 物 车 、 结 算 服 务 会 趋 于 基础 化 、 通 用 
化 ， 而 前 端 Web 会 有 各 种 各 样 的 版 本 和 需求 ， 如 PC/APP/H5/ 开 放 平 台 
等 ， 因 此 需要 进行 服务 化 平台 与 业务 系统 的 拆 分 。 


拆 分 后 ， 系 统 之 间 需 要 使 用 带 服务 注册 /发 现 功能 的 SOA 框 架 来 进行 交 
互 ， 如 Dubbo。 服 务 化 后 ， 服 务 提供 者 可 以 根据 当前 网 站 状况 随时 扩容 。 
通过 服务 注册 中 心 ， 服 务 消费 者 不 需要 进行 任何 配置 的 更 改 ， 就 可 以 发 
现 新 的 服务 提供 者 并 使 用 它 。 


一 般 情况 下 ， 中 等 互联 网 公司 会 发 展 为 如 上 服务 化 架构 风格 ， 系 统 之 间 
通过 SOA 服 务 进行 互动 ， 按 照 不 同 的 业务 、 功 能 进行 系统 拆 分 ， 并 交 由 
不 同 的 团队 维护 。 


像 丙 品 这 种 基础 服务 ， 有 非常 多 的 系统 依赖 它 。 随 着 访问 量 的 增加 ， 尤 
其 像 单 个 读 / 单 个 写 /条 件 查 询 这 类 访问 ， 会 因为 某 一 种 操作 出 现 异常 造成 
其 他 操作 不 可 用 。 因 此 ， 我 们 需要 把 这 些 操作 进行 拆 分 ， 拆 分 到 不 同 的 
服务 中 ， 从 而 使 写 出 现 问题 时 不 会 影响 到 读 。 另 外 ， 因 为 进行 了 系统 拆 
分 ， 主 数据 库 同 缓存 /ES 同步 时 会 有 一 定 的 延迟 ， 如 采 需 要 强 一 致 性 的 
读 ， 那 么 直接 读 主 库 吧 。 但 是 ， 不 是 所 有 的 系统 都 需要 读 主 库 ， 要 做 出 
限制 。 随 着 应 用 部 署 数量 的 增多 ， 数 据 库 连 接 也 会 成 为 瓶 须 ， 一 般 会 通 


过 主 从 架构 提升 连接 数 。 也 可 以 使 用 MyCat/Corbar 这 种 数据 库 中 间 件 提升 

连接 数 。 所 有 应 用 只 调用 读 / 写 服务 中 间 件 ， 由 读 / 写 服务 中 间 件 访问 数据 

^ 然后 通过 MQ 异 构 数 据 ， 从 而 不 访问 有 瓶颈 的 数 
车 o 
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随 着 流量 变 大 ， 绥 存 、 限 流 、 防 刷 需 求 变 得 越 来 越 多 ， 此 时 可 以 将 缓存 / 
限 流 / 防 刷 从 各 应 用 系统 中 拆 出 来 ， 放 到 单独 系统 实现 ， 即 接 入 层 。 


接 入 层 
Nginx | Nginx | GS | 
应 用 系统 
单 品 页 系统 || 单 品 页 系统 | | 


另外 ， 随 着 网 站 发 展 ， 对 网 站 的 性 能 、 可 用 性 要求 越 来 越 高 ， 对 于 前 端 
ae ee ane 并 且 业 务 系统 要 文 持 多 机 房 多 活 ， 如 下 
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天 机房 一 一 一 — www.***cdn.com 


负载 均衡 器 负载 均衡 器 负载 均衡 器 负载 均衡 器 
mnm. i MENS, E 


网 站 首页 系统 | 网 站 首页 系统 | o 网 站 首页 系统 | 网 站 首页 系统 |。 -…-- | 


当 其 中 一 个 机 房 出 问题 时 ， 应 该 能 比较 快速 地 切换 到 另 一 个 机 房 。 使 用 
BIND 可 以 根据 用 户 IP 将 不 同 区 域 的 用 户 路 由 到 离 他 最 近 的 机 房 来 提供 服 
务 ， 从 而 减少 访问 延迟 。 


通过 应 用 拆 分 和 服务 化 后 ， 扩 容 变 得 更 加 容易 ， 如 系统 处 理 能 力 跟 不 
上 ， 只 需要 增加 服务 器 即 可 。 


14.4 BORER 


随 着 流量 的 增加 ， 数 据 库 的 压力 也 会 随 之 而 来 ， 一 般 会 伴随 着 应 用 拆 分 
进行 数据 库 拆 分 。 如 下 岁 所 示 ， 按 照 业务 维度 进行 垂直 拆 分 ， 目 的 是 解 
决 多 个 表 之 间 的 IO 竞 争 、 单 机 容量 问题 等 。 


数据 库 
| 商品 || 订单 || 用 户 | 


数据 库 | | 数据 库 
[irs ] | Gar 


pe m | 
BEE 


| 数据 库 


拆 分 后 会 出 现 ， 原 来 可 以 进行 单 库 join 查 询 ， 现 在 不 可 以 了 ， 需 要 解决 跨 
库 join， 还 要 解决 分 布 式 事务 等 问题 。 跨 库 join 可 以 考虑 通过 如 全 局 表 、 
ES 搜索 等 异 构 数据 机 制 来 实现 。 数 据 库 垂直 拆 分 中 还 存在 一 种 宽 表 拆 多 
个 小 表 的 场景 ， 不 过 一 般 在 设计 时 束 会 做 这 件 事情 。 


按照 不 同业 务 拆 分 后 ， 随 着 流量 的 增加 ， 像 商品 这 种 读 多 写 少 的 数据 库 
BSF SHEA, UCN ALTE SORA, FEA SETHE ° 

| 主 数据 库 | | 主 数据 库 | | 主 数据 库 
商品 订单 | | | | 用户 
从 数据 库 | | 从 数据 库 | | 从 数据 库 
商品 | | || 订单 | ||| 用 户 


随 着 流量 和 数据 量 的 增加 ， 单 库 单 表 会 遇 到 容量 和 磁盘 /市 宽 IO 瓶 颈 ， 单 
和 此 时 束 需 要 分 库 、 分 表 ， 或 者 分 库 
AME e 
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商品 数据 库 
商品 表 | 商品 属性 表 商品 图 片 表 | 商品 介绍 表 | 


商品 数据 库 - 分 库 1 商品 数据 库 - 分 库 2 
| 商品 表 -分 表 1 NE o 商品 表 - 分 表 1 商品 属性 -分 表 1 
| 商品 表 -分 表 2 商品 属性 -分 表 2 商品 表 -分 表 2 =| 商品 属性 -分 表 2 


商品 介绍 mongodb 集 群 


分 库 分 表 是 一 种 水 平 数据 拆 分 ， 会 按照 如 ID、 用 户 、 时 间 等 维度 进行 数 
据 拆 分 ， 拆 分 算法 可 以 是 取 模 、 哈 硕 、 区 间或 者 使 用 数据 路 由 表 等 。 


这 也 导致 了 前 文中 说 的 跨 库 /器 表 join、 排 序 分 页 、 自 增 ID、 分 布 式 事 务 
等 问题 。 对 于 跨 库 / 跨 表 join 和 排序 分 页 ， 可 以 对 所 有 表 进 行 扫描 然后 做 率 
合 ， 或 者 生成 全 局 表 、 进 行 查询 维度 的 数据 异 构 (比如 ， 订 单 库 按照 查 
询 维度 异 构 出 商家 订单 库 、 用 户 订 单 库 ) ， 再 或 者 将 数据 同步 到 ES 搜 
索 。 目 增 ID 问 题 可 以 通过 不 同 表 、 不 同 目 增 步 长 或 分 布 式 ID 生 成 侨 解 
决 。 而 分 布 式 事务 可 以 考虑 事务 表 、 补 偿 机 制 (执行 / 回 深 ) 、TCC 模 式 

( 预 占 /确认 /取消 ) 、Sagas 模 式 〈 拆 分 事务 + 补偿 机 制 ) 等 ， 业 务 应 尽量 
设计 为 最 终 一 致 性 ， 而 不 是 强 一 致 性 。 


对 于 一 些 特殊 数据 ， 我 们 可 以 考虑 NoSQL ， 如 商品 介绍 很 适合 存储 在 
mongodb 集 群 中 。 


对 于 互联 网 应 用 ， 尤 其 是 商品 系统 ， 读 流量 可 能 是 写 流 量 的 几 十 倍 ， 而 
单个 商品 的 碍 询 会 非常 多 ， 此 时 ， 可 以 考虑 使 用 如 Redis 进 行 数据 缓 存 ， 
如 下 图 所 示 。 


redis.***.|ocal 


负载 均衡 器 
HaProxy 


负载 均衡 器 
HaProxy 


负载 均衡 器 
HaProxy 
Twemproxy 


192.168.1.1 192.168.1.2 
， Redis 实 例 1 
l Redis 实 例 2 
l Redis 实 例 3 


部 署 多 个 Redis 实 例 ， 通 过 Twemproxy 并 使 用 一 致 性 哈 硕 算 法 进行 分 片 ， 
先 通过 HapProxy 进 行 Twemproxy 的 负载 均衡 ， 然 后 通过 内 网 域名 进行 访 
问 。 

还 有 如 购物 车 数据 ， 是 用 户 维 度数 据 ， 我 们 完全 可 以 全 量 存储 到 KV 存储 


中 ， 如 使 用 Redis 进 行 存储 。 为 了 数据 的 安全 性 ， 我 们 采用 了 双 写 架构 ， 
如 下 图 所 示 。 


Twemproxy 


购物 车 服务 集群 


一 一 


| 主 Redis 集 群 1 | 主 Redis 集 群 2 
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从 Red 集 群 从 Redis 集 群 从 Redis 集 群 从 RedE 集 群 


最 简单 的 办 法 是 在 多 个 集群 间 通 过 主 从 来 解决 ， 不 过 主 从 切换 比较 麻 
烦 ， 当 主 从 断 开 后 需要 全 量 更 新 时 恢复 较 慢 。 


也 可 以 使 用 程序 双 写 ， 实 现 逻 辑 比 较 简 单 且 切换 方便 。 程 序 双 写 可 以 是 
程序 同步 双 写 ， 写 失败 其 中 一 个 殉 都 失败 。 这 种 方式 性 能 差 ， 不 适合 多 
机 房 同步 写 ， 也 不 适合 同步 写 多 个 集群 。 


还 可 以 使 用 异步 双 写 ， 首 先 把 变更 发 布 到 数据 总 线 (如 通过 MQ 实现 ) ， 
然后 订阅 数据 总 线 变 更 ， 弄 步 写 其 他 集群 。 这 种 方式 的 优点 是 性 能 好 ， 
缺点 是 异步 同步 有 一 定 的 时 延 ， 数 据 一 致 性 差 一 些 ， 应 考虑 使 用 一 致 性 
哈 希 把 用 户 调度 到 同一 个 集群 ， 防 止 用 户 刷新 多 次 看 到 不 一 样 的 数据 。 


实时 价格 类 似 于 购物 车 染 构 ， 因 为 查询 量 非常 大 ， 我 们 会 通过 挂 更 多 的 
从 来 扩展 读 的 能 力 ， 如 下 图 所 示 。 


价格 服务 集群 | 


= 


主 Redis 集 群 1 主 Redis 集 群 2 | 
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| 从 Redis 集 群 | | 从 Redis 集 群 | | 从 Redis 集 群 | | 从 Redis 集 群 | 


一 一 一 一 一 一 


| 从 Redis 集 群 | | 从 Redis 集 群 | | 从 Redis 集 群 | | 从 Redis 集 群 


Redis 使 用 内 存 复制 缓存 区 来 存放 主 从 之 间 要 同步 的 数据 。 当 主 从 断 开 时 

间 较 长 时 ， 复 制 缓冲 区 达到 阐 值 ， 此 时 旧 缓 存 数据 会 被 丢弃 ， 此 时 断 开 

v COMER T 。Redis 也 没有 提供 类 似 于 mysql binlog 的 
[| o 


到 此 应 用 拆 分 和 数据 库 拆 分 就 介绍 完了 。 应 用 扩容 可 以 通过 部 署 更 多 的 
应 用 实例 来 解决 ， 无 法 部 署 更 多 的 实例 时 ， 就 需要 考虑 系统 拆 分 或 者 重 
新 架构 。 而 数据 库 扩 容 首 移 是 人 硬件 层面 ， 然 后 按照 业务 进行 垂直 拆 分 ， 
接着 进行 水 平 拆 分 ， 最 后 根据 流量 场景 进行 读 写 分 离 ， 还 可 以 将 读 流量 
分 流 到 NoSQL 上。 


14.5 数据库 分 库 分 表示 例 


数据 库 分 库 分 表 后 整 会 涉及 如 何 写 入 和 读 取 数据 的 问题 ， 应 用 开发 人 员 
主要 关心 如 下 几 个 问题 。 


-是否 需 要 在 应 用 层 做 改造 来 文 持 分 库 分 表 ， 即 是 在 应 用 层 进 行文 择 ， 还 
征 通 过 中 间 件 层 呢 ? 


.如果 需 要 应 用 层 做 支持 ， 那 么 分 库 分 表 的 算法 是 什么 ? 
分 库 分 表 后 ，join 是 否 支持 ， 排 序 分 页 是 否 支持 ， 事 务 是 否 支持 。 
14.51 ”应 用 层 还 是 中 间 件 层 

分 库 分 表 可 以 在 应 用 层 实现 ， 也 可 以 在 中 间 件 层 实现 ， 中 间 件 层 实现 的 


ee 应 用 就 像 查 单 库 单 表 一 样 去 查询 中 间 件 层 ， 如 下 图 
AES 
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DIT 商品 属性 -分 表 1 
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商品 表 -分 表 2 | 商品 属性 -分 表 2 | 


商品 数据 库 - 分 库 1 


商品 属性 -分 表 1 | 


-] 商品 属性 -分 表 2 | 


使 用 数据 库 中 间 件 层 还 有 一 个 好 处 是 可 以 支持 多 种 编程 语言 ， 而 不 受 限 
于 特定 的 语言 。 使 用 数据 库 中 间 件 层 可 以 减少 应 用 的 总 数据 库 连接 数 ， 

从 而 避免 因为 应 用 过 多 导致 数据 库 连 接 不 够 用 。 缺 点 是 除了 维护 中 间 件 
外 ， 还 要 考虑 中 间 件 的 HA/ 负 载 均衡 等 ， 增 加 了 部 署 和 维护 的 困难 ， 
ie 还 是 要 看 当前 阶段 有 没有 必要 使 用 中 间 件 和 有 没有 人 维护 该 中 间 


目前 开源 的 数据 库 中 间 件 有 基于 MySQL-Proxy 开 发 的 奇 虎 360 的 Atlas、 阿 
里 的 Cobar、 基 于 Cobar 开 发 的 Mycat 等 。 京 东 内 部 也 有 很 多 分 库 分 表 实 
现 ， 还 有 如 JProxy 分 布 式 数 据 库 实现 ， 截 止 本 书 出 版 前 暂 未 开源 。Atlas 


只 文 持 分 表 或 分 库 (sharding 版 本 ) 、 读 写 分 离 等 ， 不 支持 跨 库 分 表 (如 
分 3 个 库 每 个 库 3 张 表 ) ，sharding 版 本 不 支持 跨 库 操作 ( 跨 库 事 务 / 跨 库 
join) 。Cobar 支 持 分 库 不 支持 分 表 (如 每 个 库 3 个 表 ) ， 不 文 持 跨 库 
join/ 分 页 /排序 等 。Mycat 支 持 分 库 分 表 、 读 写 分 离 、 跨 库 弱 事务 支持 ， 对 
跨 库 join 等 有 限 文 持 (内 存 聚 合 。 这 些 中 间 件 目前 主要 支持 MySQL， 但 
MyCat 也 提供 了 对 Oracle 等 数据 库 的 支持 。 


而 应 用 层 可 以 在 JDBC HK WB +. DAOK BRE, 如 
iBatis/Mybatis/Hibernate/JPA E JZ A » 414 4 BJ sharding-jdbc X: JDBC JI 5) 
层 实现 ， 而 阿里 的 cobar-client 是 基于 DAO 框 架 iBatis 实 现 ， 如 下 图 所 示 。 
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商品 数据 库 -分 库 1 商品 数据 库 -分 库 2 
| 


| 商品 表 -分 表 1 | 商品 属性 -分 表 1 商品 表 -分 表 1 商品 属性 -分 表 1 
| | 商品 表 - 分 表 2 ] 商品 属性 -分 表 2 商品 表 -分 表 2 | | 商品 属性 -分 表 2 


应 用 系统 直接 在 应 用 代码 中 耦合 了 分 库 分 表 逻 辑 ， 然 后 通过 如 
iBatis/JDBC 直 接 分 库 分 表 实 现 。 


相对 来 说 JDBC 层 实现 的 灵活 性 更 好 ， 侵 入 性 更 少 ， 因 此 ， 本 文选 择 了 开 
源 的 当当 的 Sharding-jdbc 来 进行 讲解 。Sharding-jdbc 直 接 封 装 JDBC API, 
所 以 迁移 成 本 很 低 ， 可 以 对 如 iBatis、MyBatis、Hibermate、JPA 等 DAO 框 
染 提 供 支 持 ， 目 前 只 提供 了 MySQL 的 支持 ， 未 来 计划 支持 如 Oracle 等 数 
据 库 。sharding-jdbc 文 持 分 库 分 表 、 读 写 分 离 、 蜂 库 join/ 分 页 /排序 等 、 弱 
事务 、 柔 性 事务 (最 大 努力 送 达 ) 。 因 此 ， 在 我 们 的 场景 中 需要 使 用 的 
分 库 分 表 / 弱 事务 功能 它 都 有 。 


14.5.2 DENKA 


分 库 分 表 人 党 略 是 指 按照 什么 算法 或 规则 进行 存储 ， 它 会 影响 数据 的 写 入 
和 读 取 ， 比 如 ， 按 照 订单 人 D 分 库 分 表 ， 那 么 束 很 难 按照 客户 维度 进行 订 
单 查询 。 因 此 ， 在 进行 分 库 分 表 时 需要 慎重 考虑 使 用 什么 策略 。 币 见 的 
策略 有 取 模 、 分 区 、 路 由 表 等 。 


1. 取 模 


我 们 可 以 按照 数值 型 主键 取 模 来 进行 分 库 分 表 ， 也 可 以 按照 字符 串 主 键 
哈 希 取 模 进行 分 库 分 表 ， 常 见 的 如 订单 表 按 照 订单 人 D 分 库 分 表 ， 用 户 订 
单 表 按 照 用 户 ID 分 库 分 表 ， 产 品 表 按 照 产品 ID 分 库 分 表 。 取 模 的 优点 是 
数据 热点 分 散 ， 缺 点 是 按照 非 主键 维度 进行 查询 时 需要 跨 库 / 跨 表 碍 询 ， 
扩容 需要 建立 新 集群 并 进行 数据 迁移 。 如 条 想 减 少 扩容 时 市 来 的 麻烦 ， 
可 以 在 初期 规划 时 了 元 余 足够 数量 的 分 库 分 表 ， 比 如 一 年 规划 只 需要 分 2 个 
库 4 个 表 ， 可 以 见 余 设计 为 4 个 库 8 个 表 ，0-1 库 在 机 器 1，2-3 库 在 机 器 2， 
如 有 果 中 到 性 能 问题 时 可 以 把 1、3 库 移 到 新 的 机 右上。 如果 遇 到 容量 问 
题 ， 则 可 以 按照 如 下 步骤 进行 扩容 。 


台 物 理 机 上 有 两 个 数据 库 实 例 ， 当 遇 到 数据 库 性 能 瓶颈 时 首先 可 以 通 
过 升级 硬件 解决 ， 如 HDD 换 成 SATA SSD ` SATA SSD 换 成 PCIe SSD 或 
NVMe SSD; 升级 硬件 之 后 ， 瓶 颈 可 能 是 们 盘 空间 或 者 网 卡带 宽 。 如 果 还 
是 不 能 解决 性 能 问题 ， 接 着 通过 扩容 物理 机 来 解决 性 能 瓶颈 。 


| “分 库 分 表 组 件 FEID: ID % 库 数量 
| KID: ID / 库 数量 % 表 数 量 

HEID: ID %4 

表 ID: ID 14% 2 
| 192.168.1.1 (192.168.1.2 
order O order 1 order 2 order 3 
t order 00 t order 00 | t order 00 | | t_order_00 
| t order 01 t order 01 | t order 01 | | t order 01 


通过 扩容 硬件 提升 DB 性 能 
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192.168.1.1 192.168.1.3 | 192.168.1.2 | 192.168.1.4 
order O0 order 1 . order 2 | order 3 
t order 00 t order 00 t order 00 t order 00 
t order 01 t order 01 | t order 01 t order 01 


SLT A EEN CTS RR TEBE IRI eX d EROR I Bl RM, BY DIE 
行 成 倍 扩容 ，4 个 库 扩 容 为 8 个 库 ， 如 下 图 所 示 。 


192.168.1.1 192.168.1.3 192.168.1.2 192.168.1.4 
| order O | | order 1 order 2 | | order 3 
7 KID: ID/8962 
192.168.1.1 192.168.1.3 192.168.1.2 192.168.1.4 
| order 0 order 1 | | Order 2 | order 3 | 
order 4 | order 5 | order 6 order 7 


成 倍 扩容 后 的 数据 迁移 可 以 这 样 实现 ， 先 挂 数据 库 主 从 (order 4— 
>order 0) ， 当 数据 库 主 从 同步 完成 后 ， 停 应 用 写 数据 库 并 等 待 一 段 时 间 
以 保证 主 从 同步 完成 ， 接 着 更 新 分 库 分 表 规 则 并 局 动 应 用 进行 写 库 ， 最 
后 删除 各 个 库 的 元 余数 据 即 可 。 


分 库 数量 不 是 越 多 越 好 ， 可 以 参考 “第 12 章 连接 池 线 程 池 详解 ”相关 革 
帮 ， 分 库 太 多 会 导致 消耗 更 多 的 数据 库 连 接 ， 并 且 应 用 会 创建 更 多 的 线 
程 。 这 种 情况 下 数据 代理 中 间 件 会 是 更 好 的 选择 。 


2. 分 区 


可 按照 时 间 分 区 、 范 围 分 区 进行 分 库 分 表 ， 时 间 分 区 规则 如 一 个 月 一 个 
表 、 一 年 一 个 库 。 范 围 分 区 规则 如 0~2000 万 一 个 表 ，2000~4000 万 一 个 
表 。 如 果 分 区 规则 很 复杂 ， 则 可 以 有 一 个 路 由 表 来 存储 分 库 分 表 规 则 o 
分 区 的 缺点 是 存在 热点 ， 但 是 易于 水 平 扩 展 ， 能 避免 数据 迁移 。 


另外 ， 也 可 以 取 模 + 分 区 组 合 使 用 。 比 如 ， 系 东 一 元 夺 至 先 按 抢 宝 项 Hash 
分 库 ， 然 后 按 抢 宝 期 区 间 段 分 表 ， 更 多 细 市 可 扫 二 维 码 参 考 《 泉 东 一 元 
抢 宝 系统 的 数据 库 染 构 优化 》。 


14.5.3 ”使 用 sharding-jdbc 分 库 分 表 


在 数据 库 设 计 起 初 一 般 都 是 单 库 单 表 设计 ， 随 着 数据 量 的 增长 将 带 来 存 
储 容量 和 写 / 读 性 能 瓶颈 问题 。 如 果 是 容量 问题 ， 则 可 以 通过 分 库 到 多 人 台 
机 器 解决 。 而 引起 写 / 读 问 题 的 主要 原因 是 记录 太 多 〈 几 千 万 到 一 亿 ) ` 
列 数 太 多 、 索 引 太 多 、 查 询 太 复杂 等 引发 单 表 出 现 性 能 问题 。 出 现 性 能 
问题 要 从 很 多 维度 去 分 析 ， 如 果 经 过 分 析 得 以 解决 ， 则 我 们 可 以 继续 单 
库 分 表 ， 如 果 单 库 分 表 确 实 有 问题 ， 则 要 进行 分 库 分 表 解 决 。 比 如 ， 电 
商 系统 的 商品 数据 库 ， 就 会 存在 这 种 问题 。 为 了 演示 方便 ， 我 们 将 商品 
数据 库 分 为 2 个 库 ， 每 个 库 2 个 表 ， 使 用 MySQL 数 据 库 。 


1. 数 据 库 DDL 


每 个 库 2 个 表 ， 即 N 为 0、1，M 为 0、1， 然 后 执行 如 下 脚 


CREATE DATABASE IF NOT EXISTS product N; 
CREATE TABLE product MI 

id bigint primary key, 

title varchar (255), 

last modified datetime 
) ENGINE-InnoDB DEFAULT CHARSET-utf8; 


2. 数 据 源 配 置 


使 用 DBCP 2 配置 2 个 DataSource， abstractDataSource 把 公共 部 分 抽取 为 父 
Bean， 可 参考 “第 12 章 连接 池 线 程 池 详解 ”部 分 进行 配置 。 


<bean id="dataSource 0" parent="abstractDataSource"> 
<property name-"url" 
value="jdbc:mysql://192.168.1.2:3306/product 0"/> 
<property name-"username" value="root"/> 
<property name="password" value="root"/> 
</bean> 


<bean id-"dataSource 1" parent-"abstractDataSource"» 
Xproperty name-"url" value-"jdbc:mysql://192.168.1.3:3306/ product 1"/> 
<property name-"username" value="root"/> 
<property name="password" value="root"/> 

</bean> 


14.5.4 sharding-jdbc 分 库 分 表 配 置 
本 文 使 用 sharding-jdbc 1.3.2 依 赖 。 


<dependency> 
<groupId>com.dangdang</groupId> 
<artifactId>sharding-jdbc-core</artifactId> 
<version>1.3.2</version> 

</dependency> 

<dependency> 
<groupId>com. dangdang</groupId> 
<artifactId>sharding-jdbc-transaction</artifactId> 
<version>1.3.2</version> 

</dependency> 

<dependency> 
<groupId>com. dangdang</groupId> 
<artifactId>sharding-jdbc-config-spring</artifactId> 
<version>1.3.2</version> 

</dependency> 


如 下 配置 可 实现 分 2 个 库 ， 每 个 库 分 2 个 表 。 


«1-- 分 库 规则 --> 
«rdb:strategy id="dataSourceStrategy" 
sharding-columns-"id" 
algorithm-expression- 
"dataSource ${Math.floorMod(id.longValue(),2L) }"/> 
<!-- 分 表 规则 --> 
<rdb:strategy id="productTableStrategy" 
sharding-columns="id" 
algorithm-expression= 
"product_${Math.floorMod (Math. floorDiv (id.longValue(),2L 
),2L) }"/> 


<!-- 分 库 分 表 数 据 源 --> 
<rdb:data-source id="shardingDataSource"> 
<!-- 使 用 的 真实 数据 源 --> 
«rdb:sharding-rule data-sources-"dataSource 0,dataSource 1"> 
<rdb:table-rules> 
<!-- 分 表 规则 :分 库 策 略 、 分 表 策 略 、 逻 辑 表 名 、 实 际 表 名 --> 
<rdb:table-rule 
database-strategy="dataSourceStrategy" 
table-strategy="productTableStrategy" 
logic-table-"product" 
actual-tables-"product $(0..1)"/» 
</rdb:table-rules> 
«/rdb:sharding-rule» 
</rdb:data-source> 


分 库 /分 表 策 略 : 使 用 sharding-columns 指 定 分 库 分 表 键 algorithm- 
expression 指 定 分 库 分 表 策 略 ， 我 们 按照 ID 分 了 两 个 库 ， 每 个 库 两 张 表 ° 
算法 为 : 库 ID = id % 库 数 量 ， 表 ID = id / 库 数量 % 单 库 表 数量 。 另 一 种 
RIAN: 库 ID = id % 表 总 数量 / 单 库 表 数量 ， 表 ID = id % 表 总 数量 。 


分 库 分 表 数 据 源 : 配置 分 库 数 据 源 ， 其 会 按照 分 库 策略 (table-rule/ 
database-strategy) 选择 使 用 哪 一 个 数据 源 。 然 后 使 用 table-strategy 配 置 分 
表 策 略 来 选择 使 用 哪 一 张 表 。l1ogic-table 是 逻辑 表 名 ， 写 SQL 时 使 用 这 个 
标识 ， 然 后 会 根据 分 表 策 略 和 actual-tables 决 定 真实 表 名 。 


sharding-jdbc 的 分 库 分 表 算 法 是 独立 的 ， 即 分 库 可 以 使 用 一 套 规则 ， 分 表 
可 以 使 用 一 套 规则 ， 如 订单 库 按 照 商家 ID 分 库 ， 然 后 每 个 库 按 照 订单 ID 
分 表 。 如 有 果 你 的 分 库 分 表 策 略 太 复 杂 ， 则 可 以 使 用 algorithm-class 指 定 
SingleKeyDatabaseShardingAlgorithm/ 
MultipleKeysDatabaseShardingAlgorithm 3 
SingleKeyTableShardingAlgorithm/MultipleKeys TableShardingAlgorithm 分 
库 分 表 实 现 算 法 ， 其 文 持 单个 键 /多 个 组 合 键 作 为 分 片 键 。 分 库 分 表 算 法 
支持 如 =、BETWEEN 、IN 等 多 维度 实现 。 


1. 事 务 管理 器 配置 
配置 弱 事 务 管理 器 在 大 多 数 场景 够 用 了 。 
<!-- 事务 管理 器 ， 此 处 使 用 弱 事 务 --> 


<bean id="transactionManager" 


class="org.springframework.jdbc.datasource. 
DataSourceTransactionManager"> 
<property name-"dataSource" ref="shardingDataSource"/> 
</bean> 


此 处 我 们 使 用 了 弱 事务 机 制 ， 如 下 图 所 示 ， 事 务 不 是 原子 的 ， 可 能 提交 
分 库 1 事 务 后 ， 提 区 分 库 2 事 务 失 败 ， 造 成 跨 库 事务 不 一 致 。 可 以 考虑 
sharding-jdbc 提 供 的 柔性 事务 实现 。 


| 开始 分 库 1 事务 
开始 分 库 2 事务 


| pi 


| 提交 / 回 滚 分 库 1 事务 | 
提交 / 回 深 分 库 2 事务 | 


柔性 事务 目前 支持 最 大 努力 送 达 ， 示 来 计划 支持 TCC (Try-Confirm- 
Cancel) 。 最 大 努力 送 达 是 当 事 务 失败 后 通过 最 大 努力 反复 尝试 送 达 操作 
实现 ， 是 在 假定 数据 库 操 作 一 定 可 以 成 功 的 前 提 下 进行 的 ， 保 证 数据 最 
终 的 一 致 性 。 其 适用 场景 是 具 等 性 操作 ， 如 根据 主键 删除 数据 、 带 主键 
地 插入 数据 、 更 新 记录 最 后 状态 (如 商品 上 下 染 操 作 ) 


Sharding-JDBC 的 最 大 努力 送 达 型 柔性 事务 分 为 同步 送 达 和 异步 送 达 两 
种 ， 同 步 送 达 不 需要 ZooKeeper 和 elastic-job， 内 置 在 柔性 事务 模块 中 。 但 
是 在 有 些 场景 下 ， 事 务 需 要 经 过 一 段 时 间 才 能 准备 完毕 ， 则 可 通过 异步 
送 达 ， 异 步 送 达 比 较 复杂 ， 是 对 柔性 事务 的 最 终 补 偿 ， 不 能 和 应 用 程序 
部 署 在 一 起 ， 需 要 额外 地 通过 elastic-job 实 现 。 异 步 送 达 是 对 同步 送 达 的 
有 效 补 充 ， 但 即使 不 配置 异步 送 达 ， 同 步 送 达 机 制 也 可 以 正常 使 用 。 最 
大 努力 送 达 型 事务 也 可 能 出 现 错误 ， 即 无 论 如 何 补 傍 都 不 能 正确 提交 。 
为 了 避免 反复 尝试 带 来 的 系统 开销 ， 同 步 送 达 和 异步 送 达 均 可 配置 最 大 
重 试 次 数 ， 超 过 最 大 重 试 次 数 的 事务 将 进入 失败 列表 ， 需 要 定期 进行 人 
工 干 预 。 具 体 使 用 请 参考 sharding-jdbc 官 方 文档 。 


在 一 般 场景 中 ， 只 要 保证 单 库 事 务 能 工作 即 可 ， 跨 库 通过 一 些 机 制 保证 
最 终 一 致 性 即 可 ， 在 高 并 发 高 可 用 的 场景 下 不 应 该 采用 强 一 致 模型 。 


2. 8932 $8 
Po 时 ， 通 过 JDBC 模 板 和 编程 式 完成 事务 开发 ， 通 过 AOP 机 制 配 


事务 


// 获 取 分 库 分 表 数 据 源 
DataSource shardingDataSource = 
(DataSource) ctx.getBean ("shardingDataSource"); 
// 创 建 JdbcTemplate 
JdbcTemplate jdbcTemplate = new JdbcTemplate (shardingDataSource); 
// 获 取 事务 管理 器 
AbstractPlatformTransactionManager transactionManager = 
(AbstractPlatformTransactionManager) ctx.getBean ("transactionM 
anager") ; 
// 创 建 事务 模板 
TransactionTemplate transactionTemplate - 
new TransactionTemplate (transactionManager); 
// 执 行 SQL (product 是 逻辑 表 名 、id 是 分 库 分 表 键 ) 


transactionTemplate.execute (new TransactionCallbackWithoutResult() { 


@Override 
protected void doInTransactionWithoutResult (TransactionStatus 
transactionStatus) { 
jdbcTemplate.update ("insert into product (id, title, last_modified) 
values (?, ?, ?)", 1L, "title", new Date()); 


} 
y 


整体 使 用 和 非 分 库 分 表 没 什么 区 别 ， 在 实际 执行 时 ， 逻 辑 表 名 product 会 
被 奉 换 为 如 product_1 这 种 实际 表 名 ， 即 实际 SQL 会 是 如 下 样子 : 


INSERT INTO product. 1 (id, title, last modified) VALUES (?, ?, ?) 


14.5.5 “使 用 sharding-jdbc 读 写 分 离 

随 着 数据 库 读 访问 量 的 增长 ， 主 库 不 能 承受 更 多 的 读 访问 ， 此 时 ， 可 以 
通过 给 主 库 挂 从 库 ， 然 后 把 读 访问 分 流 到 从 库 来 减少 主 库 的 压力 。 
sharding-jdbc 通 过 简单 的 配置 就 可 以 支持 读 写 分 离 。 

读 写 分 离 数 据 源 配置 


通过 如 下 配置 就 可 以 实现 读 写 分 离 ， 即 配置 一 个 主 库 和 两 个 从 库 。 


«rdb:master-slave-data-source id="dataSource 0" 
master-data-source-ref ="dataSource master 0" 
slave-data-sources-ref-"dataSource slave 0,dataSource_slave_1"/> 


使 用 如 上 配置 读 请 求 会 通过 路 由 到 达 从 库 ， 但 是 ， 假 设 刚刚 写 入 数据 ， 

此 时 立即 读 的 话 可 能 读 不 到 ， 因 为 MySQL 默 认 使 用 异步 复制 ， 复 制 是 有 

o 因此 要 想 在 写 完 后 立即 读数 据 ， 可 以 通过 Hint 机 制 强制 读 取 
车 o 


HintManager.getInstance ().setMasterRouteOnly(); 
jdbcTemplate.queryForL ist(" select id, title form product where id=?", 1L); 


Sharding-JDBC 的 读 写 分 离 为 了 最 大 限度 避免 由 于 同步 延迟 而 产生 强制 读 
取 主 库 的 场景 ， 在 更 新 方面 做 了 优化 ， 在 一 个 请 求 线程 中 ， 只 要 存在 对 
数据 库 的 更 新 操作 ， 则 在 此 操作 之 后 的 任何 对 数据 库 的 访问 都 会 自动 通 
过 路 由 达到 主 库 。 因 此 ， 在 写 后 读 的 场景 中 不 需要 使 用 HintManager， 只 
uus 需要 强制 读 主 库 时 ， 才 使 用 HintManager 强 制 通过 路 由 到 
AE © 
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颈 ， 或 者 通过 从 库 无 法 满足 查询 需求 时 ， 应 该 选择 数据 异 构 。 


14.6 ”数据 异 构 


分 库 分 表 后 将 带 来 很 多 问题 ， 如 跨 库 join、 非 分 库 分 表 维度 的 条 件 查 询 、 
分 页 排序 等 。 前 面 我 们 提 到 了 可 以 扫描 全 部 表 通 过 内 存 聚 合 、 数 据 异 构 

(全 局 表 、ES 搜 索 、 异 构 表 ) 等 来 实现 。 数 据 异 构 主要 按照 不 同 查 询 维 
度 建立 表 结构 ， 这 样 束 可 以 按照 这 种 不 同 维度 进行 查询 。 数 据 异 构 有 查 
询 维度 异 构 、 素 合 数据 异 构 等 。 


在 数据 量 和 访问 量 双 高 时 使 用 数据 异 构 十 非常 有 效 的 ， 但 增加 了 架构 的 
复杂 度 。 腊 构 时 可 以 通过 订阅 MQ 或 者 binlog 并 解析 实现 。 


14.6.1 查询 维度 异 构 


比如 对 于 订单 库 ， 当 对 其 分 库 分 表 后 ， 如 宁 想 按照 商家 维度 或 者 按照 用 
户 维度 进行 查询 ， 那 么 是 非常 困难 的 ， 因 此 可 以 通过 弄 构 数据 库 来 解决 
这 个 问题 。 可 以 采用 下 图 的 架构 。 


商家 ID 分 库 分 表 


商家 维度 订单 分 库 1 
订单 ID 分 库 分 表 商家 维度 订单 分 库 2 
订单 分 库 1 | > 
me 
races | 用 户 ID 分 库 分 表 
用 户 维度 订单 分 库 1 
用 户 维度 订单 分 库 2 
或 者 采用 下 图 的 
ES 集群 
订单 分 库 1 » a -— | 
订单 分 库 2 4 - 


zm cns d EE 询 实 际 数据 。 
有 时 可 以 通过 数据 元 余 存储 来 减少 源 库 查询 量 或 者 提升 查询 性 


(0) 


14.6.2 RRA 


商品 详情 页 中 一 般 包 括 商 品 基 本 信息 、 商 品 属 性 、 商 品 图 片 ， 在 前 端 展 
示 商 品 详情 页 时 ， 有 是 按照 商品 ID 维度 进行 查询 ， 并 且 需 要 查询 3 个 甚至 更 
多 的 库 才 能 查 到 所 有 展示 数据 。 此 时 ， 如 果 其 中 一 个 库 不 稳定 ， 就 会 导 
致 商品 详情 页 出 现 问 题 ， 因 此 ， 我 们 把 数据 聚合 后 异 构 存储 到 KV 存储 集 
WE (如 存储 JSON) ， 这 样 只 需要 一 次 查询 就 能 得 到 所 有 的 展示 数据 。 这 
种 方式 也 需要 系统 有 了 一 定 的 数据 量 和 访问 量 时 再 考虑 。 束 东 商 品 详情 
页 就 是 采用 这 种 异 构 机 制 。 


商品 基础 库 
商品 属性 库 | 商品 KV 存储 集群 
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具体 实现 请 参考 第 15 章 中 基于 Canal 实 现 数据 异 构 部 分 。 


14.7 任务 系统 扩容 


在 开发 系统 时 ， 有 时 需要 在 特定 的 时 间 点 执行 一 些 任务 ， 或 者 周期 性 地 
执行 一 些 任务 。 比 如 ， 每 天 竣 晨 删除 过 期 的 垃圾 消息 、 每 天 次 晨 进 行 报 
表 统 计 、 每 天 凌晨 进行 数据 结 转 ， 或 者 每 隔 10 分 钟 处 理 一 次 超时 未 支付 
的 订单 、 每 隔 10 秒 删除 过 期 的 活动 等 。 对 于 一 般 单 实例 任务 ， 使 用 如 
Thread ` Timer ` ScheduledExecutor ^ Quartz HLR AET, URES 
可 用 或 分 布 式 版 本 ， 则 可 以 选择 Quartz 集 群 版 、tbschedule ` elastic-job 
等 。 


14.7.1 简单 任务 


在 一 般 情况 下 ， 我 们 使 用 Thread 就 能 满足 需求 ， 如 第 15 章 中 使 用 
EventPublishThread 线 程 抓 取 任务 并 交 给 Disruptor 处 理 。 一 般 Thread 的 使 用 
PRESE 


while(true) { 
// 任 务 处 理 
/ /休眠 等 待 


} 


即使 用 Thread， 一 般 都 是 死 循 环 抓 取 并 处 理 任务 ， 如 果 没 有 任务 ， 则 可 以 
休眠 一 下 ， 然 后 继续 尝试 抓 取 任 务 ， 为 了 保证 任务 能 及 时 被 处 理 ， 休 有 眠 
时 间 非 常 短 ， 一 般 为 几 毫 秒 到 几 秒 。 比 如 要 获取 任务 表 中 状态 为 未 处 理 
的 任务 并 进行 处 理 ， 处 理 成 功 后 将 状态 更 新 为 已 处 理 ， 则 可 以 使 用 如 上 
介绍 的 Thread 方 式 。 


如 果 需 要 周期 性 地 执行 任务 ， 则 可 以 使 用 Timer。 
Timer#schedule(TimerTask task, long delay, long period) 
// 周 期 性 地 执行 TimerTask， 首 次 执行 时 间 为 (当前 时 间 +delay) 


Timer#schedule(TimerTask task, Date firstTime, long period) 
// 周 期 性 地 执行 TimerTask， 首 次 执行 时 间 为 firstTime 


period 的 单位 为 量 秒 ， 如 果 period 为 0， 则 表示 一 次 性 任务 ， 执 行 完 成 后 将 
从 任务 队列 被 移 除 。Timer 内 部 通过 一 个 TimerThread 来 循环 执行 提交 给 
Timer 的 任务 ， 比 如 MySQL JDBC 张 动 瓯 使 用 Timer 来 处 理 Statement 执 行 超 
时 。 因 为 提交 给 Timer 的 任务 是 被 单个 TimerThread 处 理 的 ， 因 此 任务 是 

行 处 理 的 ， 前 一 个 任务 延迟 了 将 会 影响 到 后 续 所 有 任务 ， 当 然 也 可 以 启 


动 多 个 Timer 来 实现 。 但 是 ， 如 果 任 务 处 理 不 是 密集 型 的 ， 那 么 将 造成 线 
程 休眠 ， 从 而 被 浪费 ， 因 此 ， 如 果 需 要 更 灵活 的 周期 性 任务 处 理 ， 则 可 
以 使 用 ScheduledExecutorService， 它 基于 线程 池 实 现 ， 任 务 可 以 被 线程 池 
中 的 一 个 线程 处 理 ， 从 而 实现 线程 的 复 用 。 


ScheduledExecutorService#scheduleAtFixedRate(Runnable command, long 
initial Delay, long period, TimeUnit unit) /固定 速率 执行 周期 性 任务 


ScheduledExecutorService#scheduleWithFixedDelay(Runnable command, 
long initialDelay, long period, TimeUnit unit) /固定 延迟 执行 周期 性 任务 


其 中 ，initialDelay 指 定 初 次 执行 延迟 ，period 指 定 周 期 ，unit 指 定 延 迟 和 周 
期 的 时 间 单 位 。scheduleAtFixedRate 是 用 固定 速率 执行 周期 性 任务 ， 即 相 
对 于 上 一 次 任务 开始 时 间 往 后 推 period 时 间 后 执行 下 一 次 任务 。 假 设 上 一 
次 任务 开始 时 间 为 10:00 ，period 为 10s， 任 务 执行 时 长 为 ss， 那么 
scheduleAtFixedRate 在 10:10 会 执行 下 一 次 任务 ， 如 果 任 务 执行 时 长 为 
15s， 那 么 scheduleAtFixedRate 在 10:15 会 执行 下 一 次 任务 。Timer 也 是 用 
定 速率 执行 周期 性 任务 。scheduleWithFixedDelay 是 固定 延迟 执行 周期 性 
任务 ， 即 相对 于 上 一 次 任务 结束 时 间 往 后 推 period 时 间 后 执行 下 一 次 任 
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使 用 Timer 和 ScheduledExecutorService 实 现 类 似 在 每 周二 1:00:00 执 行 任务 
是 比较 麻烦 的 ， 此 时 ， 可 以 使 用 Quartz 或 者 Spring Task 实 现 。Spring Task 
配置 简单 ， 在 单 实例 任务 场景 下 ， 笔 者 偏好 于 使 用 Spring Task 实 现 。 


<task:scheduler id="scheduler" pool-size="10"/> 


<task:scheduled-tasks scheduler="scheduler"> 
<!-- 每 天 两 点 执行 -=-> 
«task:scheduled ref="relationClearTask" method-"autoClearRelation" 


cron="0 0 2 * * 2"/> 
</task:scheduled-tasks> 


cron 配 置 表达 式 和 Quartz 基 本 一 致 ， 详 细 配 置 可 以 参考 Spring 官方 文档 。 


14.7.2 ”分布 式 任务 


使 用 上 述 机 制 进行 单 实例 任务 处 理 时 是 单 点 作业 ， 如 果实 例 失 效 了 ， 那 
么 任务 可 能 得 不 到 执行 ， 男 外 ， 如 采 单 实例 任务 处 理 遇 到 瓶 贷 ， 则 不 太 


容易 做 到 动态 扩容 。 因 此 ， 我 们 需要 任务 高 可 用 和 动态 扩容 ， 此 时 束 需 
要 分 布 式 任务 。 使 用 分 布 式 任务 后 ， 当 一 个 实例 失效 ， 则 可 以 将 任务 转 
移 到 其 他 实例 进行 处 理 。 分 布 式 任务 文 持 任 务 分 片 ， 当 任务 处 理 遇 到 瓶 
贷 ， 可 以 扩充 任务 实例 来 提升 任务 处 理 能 


Quartz 文 持 任 务 的 集群 调度 ， 如 果 一 个 实例 失效 ， 则 可 以 漂移 到 其 他 实例 
进行 处 理 ， 但 是 其 不 文 持 任务 分 片 。tbschedule 和 elastic-job 除 了 文 持 集群 
调度 特性 ， 还 文 持 任务 分 片 ， 从 而 可 以 进行 动态 扩容 / 缩 容 。tbschedule 和 
elastic-job 都 能 满足 我 们 的 场景 需求 。 在 本 书 出 版 时 ， 唯 品 会 也 开源 了 基 
于 elastic-job 开 发 的 Satum， 京 东 内 部 也 有 相关 实现 ， 但 在 本 书 出 版 前 暂 未 
开源 。 本 章 选 择 elastic-job 来 讲解 分 布 式 任务 。 


14.7.3 Flastic-JobfBj 4r 


Elastic-Jobzé 4 4 JFJRBS— 3x PTE aE, H AIEE T TAL 
子 项 目 : Elastic-Job-LitefliElastic-Job-Cloud ° 


Flastic-Job-Lite 定 位 为 轻 量 级 无 中 心 解决 方案 ， 可 以 动态 暂停 /恢复 任务 实 
例 ， 目 前 不 文 持 动态 扩容 任务 实例 。Elastic-Job-Cloud 使 用 Mesos + Docker 
解决 方案 ， 可 以 根据 任务 负载 来 动态 实现 局 动 /停止 任务 实例 ， 以 及 任务 
治理 。Elastic-Job-Cloud 目 前 还 处 于 开发 中 。Elastic-Job-Lite 和 Elastic-Job- 
Cloud 使 用 同一 套 任务 API， 一 次 开发 并 根据 需要 以 Lite 或 Cloud 的 方式 部 
署 。 本 书 会 重点 介绍 Elastic-Job-Lite。 关 于 Elastic-Job-Cloud， 可 以 从 官网 
中 了 解 其 最 新 动向 。 


14.7.4 Elastic-Job-Lite 功 能 与 架构 


Elastic-Job-Lite 实 现 了 分 布 式 任务 调度 、 动 态 扩 容 缩 容 、 任 务 分 片 、 失 效 
转移 、 运 维 平 台 等 功能 。 


1. 整 体 架 构 


任务 实例 


Elastic-Job-Lite 分 片 1 = 
Elastic-Job-Lite 4} Hj 2 Elastic-Job-Lite4} 43 
[ 


监听 


Elastic-Job-Lite Console 


Elastic-Job-Lite 采 用 去 中 心 化 的 调度 方案 ， 由 Elastic-Job-Lite 的 客户 端 定 时 
目 动 触发 任务 调度 ， 通 过 任务 分 片 的 概念 实现 服务 器 负载 的 动态 扩容 / 缩 
容 ， 并 且 使 用 ZooKeeper 作 为 分 布 式 任务 调度 的 注册 和 协调 中 心 ， 当 某 任 
FEAR, AMES, SATA, Heese ISA, Se 
现任 务 参数 的 动态 修改 。 


2. 任 务 分 片 


任务 如 果 并 行 处 理 或 者 分 布 式 处 理 ， 则 需要 使 用 任务 分 片 ， 即 把 任务 拆 
成 N 个 子 任 务 。 比 如 ， 我 们 需要 遍历 某 张 数据 库 表 ， 现 在 有 1 台 服 务 器 ， 
为 了 实现 多 线程 处 理 ， 此 时 可 以 将 数据 分 片 为 10 份 ， 如 id % 10, ALAS 
有 10 个 线程 并 发 处 理 这 些 任务 ， 从 而 提升 了 处 理性 能 。 如 果 有 两 台 服 务 
器 ， 并 且 还 将 数据 分 片 为 10 份 ， 如 id % 10， 那 么 机 器 1 会 处 理 1,3,5,7,9; 
机 器 2 会 处 理 0,2,4,6,8; 每 台 机 器 是 5 个 线程 并 发 处 理 任务 。 通 过 任务 分 片 
可 以 实现 任务 并 发 处 理 ， 通 过 增加 机 器 可 以 实现 动态 扩容 / 缩 容 。 


14.7.5 Elastic-Job-Litezr (| 


1. 启 动 ZooKeeper 


Elastic-Job 使 用 ZooKeeper 进 行 分 布 式 任务 调 度 〈 本 和 使 用 的 是 ZooKeeper- 
3.4.9) ， 执 行 如 下 脚本 后 启动 ZooKeeper 。 


./bin/zkServer.sh start 


2. 添 加 Elastic-Job-Lite 依 赖 


下 面 添加 Elastic-Job-Lite 依 赖 (本 文 使 用 最 新 的 Elastic-Job-Lite 2.x) ， 其 
API 与 1.x 完 全 不 同 。 


<dependency> 
<groupId>com.dangdang</groupId> 
<artifactId>elastic-job-lite-core</artifactId> 
<version>2.0.0</version> 

</dependency> 

<dependency> 
<groupId>com.dangdang</groupId> 
<artifactId>elastic—job-lite-spring</artifactId> 
<version>2.0.0</version> 

</dependency> 


3. 任 务 开发 


为 了 便于 统一 名 词 ， 在 本 书 中 不 区 分 任务 与 作业 。Elastic-Job 提 供 了 三 种 
类 型 的 任务 : Simple 类 型 任务 (最 简单 的 实现 ， 支 持 分 片 特性 ) ` 
Dataflow 类 型 任务 〈 将 任务 的 数据 抓 取 和 处 理 分 离 ) 和 Script 类 型 任务 
(脚本 类 型 任务 ， 如 ShelyPython 脚 本 等 ) ° 


Simple 类 型 任务 


public class MySimpleJob implements SimpleJob { 
public void execute(ShardingContext shardingContext) { 
switch (shardingContext.getShardingItem()) { 
// 任 务 按照 主键 ID 分 3 片 (ID $ 3) 
case 0: // 分 片 0 
process(fetch(0, 3, 6, 9)); 
break; 
case 1: // 分 片 1 
process(fetch(1, 4, 7)); 
break; 
case 2: // 分 片 2 
process(fetch(2, 5, 8)); 
break; 


通过 Simple 类 型 任务 实现 SimpleJob#execute 妈 可， 然后 再 根据 分 片 配置 信 
时 进 行 分 片 处 理 实现 。 


Dataflow 类 型 任务 


public class MyDataflowJob implements DataflowJob<String> { 
public List«String» fetchData(ShardingContext shardingContext) { 


switch (shardingContext.getShardingItem()) ( 
// 任 务 按照 主键 ID 分 3 片 (ID $ 3) 
case 0: // 分 片 0 
return fetch(0, 3, 6, 9); 
case 1: // 分 片 1 
return fetch(0, 3, 6, 9); 
case 2: // 分 片 2 
return fetch(0, 3, 6, 9); 
) 
return null; 
} 
public voidprocessData(ShardingContext shardingContext, List<String> 
data) { 
// 任 务 处 理 


) 


Dataflow 类 型 任务 将 任务 分 为 抓 取 数 据 (fetchData ). 和 处 理 数据 

(processData) 两 部 分 。 其 中 ， 流 式 任务 只 有 当 fetchData 方 法 返回 值 为 
null 时 ， 任 务 才 停 止 抓 取 ， 否 则 任务 将 一 直 运 行 下 去 。 非 流 式 任务 在 每 次 
任务 执行 过 程 中 ， 只 执行 一 次 fetchData 和 processData 方 法 。 可 以 在 任务 配 
置 时 ， 设 置 是 否 是 流 式 任务 。 


4. 任 务 配 置 与 启动 


Elastic-Job 文 持 Java 配 置 和 Spring 配置 文件 配置 任务 ， 本 文选 择 使 用 Spring 
配置 文件 配置 。 


配置 ZK 注册 中 心 


«reg:ZooKeeper id="regCenter" 
server-lists-"192.168.61.129:2181" 
namespace-"my-job" 
connection-timeout-milliseconds-"2000" 
session-timeout-milliseconds-"3000" 
base-sleep-time-milliseconds-"1000" 
max-Sleep-time-milliseconds="3000" 


max-retries-"3"/» 


Elastic-Job{i FH Apache Curator 客 户 端 来 连接 ZK， 配 置 参 数 如 下 所 示 。 
server-lists: ZooKeeper 服 务 锅 列表 ， 多 个 地 址 用 喜 号 分 隅 。 


namespace: 当前 注册 中 心 使 用 的 是 ZooKeeper 命 名 空间 ， 不 同类 型 的 任 
务 可 以 放 到 不 同 的 命名 空间 e 


connection-timeout-milliseconds: ZK 和 连接 超时 时 间 ， 默 认为 15000ms。 


session-timeout-milliseconds: ZK 会 话 超 时 时 间 ， 默 认为 60000ms。 
digest: 连接 ZK 时 的 权限 令 牌 ， 默 认 不 需要 权限 验证 。 


base-sleep-time-milliseconds: 使 用 ExponentialBackoffRetry 指 数 退 避 算 法 
重 试 时 的 初始 重 试 时 间 ， 软 认为 1000ms。 


max-sleep-time-milliseconds: 使 用 ExponentialBackoffRetry 指 数 退 避 算 法 
重 试 时 的 最 大 重 试 时 间 ， 移 认为 3000ms。 


max-retries: 使 用 ExponentialBackoffRetry 指 数 退 避 算 法 的 最 大 重 试 次 
ZW o 


配置 Simple 类 型 任务 


<job:simple registry-center-ref="regCenter" 
id="mySimpleJob" 
class="com.elasticjob.MySimpleJob" 
6Hon="0/10 * * - o» wm 


sharding-total-count="3" 


sharding-item-parameters="0=A, 1=B, 2=C" 
job-parameter="pageSize=5" 
disabled="false" 

overwrite="false"/> 


配置 参数 如 下 所 示 。 

registry-center-ref: 配置 使 用 的 注册 中 心 。 

id: 任务 /作业 名 称 。 

class: Simple 类 型 任务 实现 类 。 

cron: cron 表 达 式 ， 配 置 作 业 触发 时 间 ， 目 前 使 用 Quartz 表 达 式 。 


sharding-total-count: 总 的 任务 分 片 数 ， 通 过 它 来 实现 任务 并 发 执行 和 
4] BA? 


sharding-item-parameters: 分 片上 序号 和 参数 关系。 


job-parameter: 任务 目 定 义 参 数 ， 如 每 次 查询 数据 库 表 的 每 页 记录 数 ， 
通过 它 可 以 实现 动态 分 页 参数 配置 。 


diasbled: ”任务 默认 是 否 是 禁止 启动， 当 部 署 任 务 时 需要 先 林 用， 部署 后 
统一 局 动 时 可 以 配置 。 


overwrite: 是 否 使 用 本 地 参数 配置 履 盖 注册 中 心 配置 ， 如 果 和 覆盖 ， 那 么 
任务 局 动 时 以 本 地 配置 参数 为 准 。 


job-sharding-strategy-class: 任务 分 片 算法 ， 默 认 使 用 平均 分 配 算法 ， 可 
以 进行 算法 的 自 定义 。 


这 里 要 注意 以 下 几 上 总 。 


:任务 实例 是 以 服务 器 ID+JOB ID 作为 唯一 标识 来 区 分 的 ， 即 使 一 台 服 务 
堪 部 署 了 多 个 实例 ， 目 前 Elastic-Job 也 会 把 它们 看 作 同 一 个 实例 ， 如 有 果 同 


台 服 务 器 部 嗜 多 个 实例 ， 则 可 能 导致 相同 任务 的 重复 执行 。 因 此 一 人 台 
HRA a 


应 只 部 署 一 个 任务 实例 。 

:任务 的 参数 在 任务 实例 第 一 次 启动 后 注册 到 注册 中 心 ， 之 后 任务 实例 重 
启 后 ， 任 务 参数 将 以 注册 中 心 的 为 准 ， 更 改 本 地 配置 是 不 起 作用 的 ， 可 
以 在 任务 控制 台 进 行 参数 更 改 。 如 果 配 置 了 overwrite=true， 则 将 以 本 地 
配置 为 准 。 


sharding-item-parameters 可 以 为 不 同 的 任务 分 片 配置 个 性 化 参数 ，job- 
parameter 可 以 为 所 有 的 任务 分 片 配置 参数 。 


任务 类 中 的 ShardingContext 提 供 了 任务 分 片上 下 文 参数 。 


-jobName: 任务 名 称 /ID。 


-jobParameter: 任务 自 定义 参数 。 

-shardingTotalCount: ”总 的 分 片 数量 ， 可 以 根据 它 分 别 抓 取 任 务 数据 。 
shardingItem: 分 配 本 任务 实例 的 分 片 序 号 。 

shardingParameter: 分 配 本 任务 实例 的 分 片 参数 。 

配置 Dataflow 类 型 任务 


<job:dataflow registry-center-ref="regCenter" 
id="myDataflowJob" 
class="com.elasticjob.MyDataflowJob" 
GronsWwse/10 > sow MW 
streaming-process="false" 
sharding-total-count="3" 


sharding-item-parameters="0=A, 1=B, 2=C" 
job-parameter-"pageSize-5" 
disabled="false" 

overwrite="false"/> 


参数 配置 和 Simple 类 型 任务 差不多 ， 只 是 多 了 一 个 streaming-process， 然 
后 判断 其 配置 是 否 是 流 式 处 理 数据 ， 如 果 是 流 式 处 理 数据 ， 那 么 
fetchData 方 法 返回 空 时 ， 才 结束 执行 任务 。 如 果 是 非 流 式 处 理 数据 ， 那 
入 只 执行 一 次 fetchData 和 processData 方 法 ， 然 后 任务 执行 就 结束 了 。 


接着 局 动 加 载 Spring 配置 文件 的 JVM 实 例 ， 即 可 局 动 任务 。 


任务 控制 台 


Elastic-Job-Lite 提 供 了 elastic-job-lite-console 控 制 台 ， 用 于 动态 配置 任务 。 
下 载 elastic-job-lite-console 并 部 署 到 Tomcat 中 ， 然 后 启动 即 可 。 


添加 注册 中 心 


首先 ， 需 要 添加 注册 中 心 ， 如 下 图 所 示 。 然 后 束 可 以 对 该 注册 中 心 的 任 
务 进行 维护 了 。 


注册 中 心 名 称 : 
regCenter 

注册 中 心地 址 : 
192.168.61.129:2181 


任务 配置 
通过 任务 控制 台 可 以 进行 任务 /作业 的 参数 动态 更 改 ， 如 下 图 所 示 。 


作业 设置 作业 服务 器 作业 运行 状态 


作业 实现 类 com.elasticjob.MyDataflowJob 


作业 类 型 DATAFLOW 


作业 分 片 总 数 3 自 定义 参数 abc=5 cron 表 达 式 0/10 ss= 1 ? 
最 大 容忍 的 本 机 与 注册 -1 监听 作业 端口 -1 是 否 流 式 处 理 数据 
中 心 的 时 间 误 差 秒 数 
监控 作业 执行 时 状态 关 支持 自动 失效 转移 支持 misfire 


分 片 序列 号 /参数 对 照 表 O=A,1=B,2=C 


y 策略 实现 类 com.dangdang.ddframe job lite.api.strategy.impl.AverageAllocationJobShardingStrategy 
9 9 E 9 9 9 
路 径 
定制 异常 处 理 类 全 路 径 com.dangdang.ddframe job.executor handler impl.DefaultJobExceptionHandler 
定制 线程 池 全 路 径 com.dangdang.ddframe job.executorhandlerimpLDefaultExecutorServiceHandler 


至 此 使 用 Elastic-Job-Lite 开 发 分 布 式 任务 束 介 绍 完了 。 


15 ”队列 术 


队列 ， 在 数据 结构 中 是 一 种 线性 表 ， 从 一 剖 插 入 数据 ， 然 后 从 男 一 端 删 
除数 据 。 本 书 的 目的 不 是 讲解 各 种 队列 及 如 何 实现 ， 而 是 讲述 在 应 用 层 
面 使 用 队列 能 解决 哪些 场景 问题 。 


在 我 们 的 系统 中 ， 不 是 所 有 的 处 理 都 必须 实时 处 理 ， 不 是 所 有 的 请 求 都 
必须 实时 反馈 结果 给 用 户 ， 不 是 所 有 的 请 求 都 必须 100% 一 次 性 处 理 成 
功 ， 不 知道 哪个 系统 依赖 “我 ?来 实现 其 业务 处 理 ， 保 证 最 终 一 致 性 ， 不 
需要 强 一 致 性 。 此 时 ， 我 们 应 该 考虑 使 用 队列 来 解决 这 些 问 题 。 当 然 我 
们 也 要 考虑 是 否 需 要 保证 消息 处 理 的 有 序 性 及 如 何 保证 ， 是 否 能 重复 消 
费 及 如 何 保证 重复 消费 的 暴 等 性 。 在 实际 开发 时 ， 我 们 经 常 使 用 队列 进 
行 异 步 处 理 、 系 统 解 耦 、 数 据 同步 、 流 量 削 峰 、 扩 展 性 、 绥 冲 等 。 


15.31 ”应 用 场景 


异步 处 理 : 使 用 队列 的 一 个 主要 原因 是 进行 异步 处 理 ， 比 如 ， 用 户 注册 
成 功 后 ， 需 要 发 送 注册 成 功 邮 件 / 新 用 户 积分 /优惠 券 等 ;缓存 过 期 时 ， 先 
返回 过 期 数据 ， 然 后 异步 更 新 缓存 、 异 步 写 日 志 等 。 通 过 异步 处 理 ， 可 
以 提升 主流 程 啊 应 速度 ， 而 非 主流 程 / 非 重 要 处 理 可 以 集中 人 处理 ， 这 样 还 


可 以 将 任务 聚合 批量 处 理 。 因 此 ， 可 以 使 用 消息 队列 /任务 队列 来 进行 异 
步 处 理 。 


` 系统 解 而 ， 比如， 用 户 成 功 支 付 完成 订单 后 ， 需 要 通知 生产 配 货 系统 、 
发 票 系统 、 库 存 系统 、 推 荐 系统 、 搜 索 系 统 等 进行 业务 处 理 ， 而 未 来 需 
要 文 持 哪些 业务 是 不 知道 的 ， 并 且 这 些 业 务 不 需要 实时 处 理 、 不 需要 强 
一 致 ， 只 需要 保证 最 终 一 致 性 即 可 ， 因 此 ， 可 以 通过 消 妃 队列 /任务 队列 
BEAT ASTER © 


-数据 同步 ， 比 如 ， 想 把 MySQL 变 更 的 数据 同步 到 Redis， 或 者 将 MySQL 
的 数据 同步 到 Mongodb ， 或 者 让 机 房 之 间 的 数据 同步 ， 或 者 主 从 数据 同 
步 等 ， 此 时 可 以 考虑 使 用 databus、canal 、otter 等 。 使 用 数据 总 线 队 列 进 
行 数 据 同步 的 好 处 是 可 以 保证 数据 修改 的 有 序 性 。 


流量 削 峰 : 系统 瓶颈 一 般 在 数据 库 上 ， 比 如 扣 减 库存 、 下 单 等 。 此 时 可 
以 考虑 使 用 队列 将 变更 请 求 暂 时 放 入 队列 ， 通 过 缓存 + 队列 暂 存 的 方式 将 
数据 库 流量 削 峰 。 同 样 ， 对 于 秒杀 系统 ， 下 单 服务 会 是 该 系统 的 瓶 贷 ， 
此 时 ， 可 以 使 用 队列 进行 排队 和 限 流 ， 从 而 保护 下 单 服务 ， 通 过 队列 暂 
存 或 者 队列 限 流 进行 流量 削 峰 。 


队列 的 应 用 场景 非常 多 ， 以 上 只 列举 了 一 些 稼 见 用 法 和 萄 景 。 


15.2 ”缓冲 队列 


典型 的 如 Log4j 日 志 绥 冲 区 ， 当 我 们 使 用 log4j 记 隶 日 志 时 ， 可 以 配置 字 届 
绥 冲 区 ， 字 节 缓 存 区 满 时 ， 会 立即 同步 到 磁盘 。Log4j 是 使 用 
BufferedWriter 实 现 的 。 此 模式 不 是 异步 写 ， 在 缓冲 区 满 的 时 候 还 是 会 阻 
塞 主线 程 。 如 果 需 要 异步 模式 ， 则 可 以 使 用 AsyncAppender， 然 后 通过 
bufferSize 控 制 日 志 事 件 绥 冲 区 大 小 。 


同样 ， 在 电 商 进行 大 促 时 ， 此 时 的 系统 流量 会 高 于 平常 流量 的 几 倍 甚 至 
几 十 倍 ， 此 时 应 进行 一 些 特殊 的 设计 来 保证 系统 平稳 度 过 这 段 时 期 。 而 
解决 的 手段 很 多 ， 一 般 牺 牲 业务 的 强 一 致 性 ， 保 证 最 终 一 致 性 即 可 。 


如 下 图 所 示 ， 使 用 缓冲 队列 应 对 突 发 流量 时 ， 并 不 能 使 处 理 速 度 变 快 ， 
而 是 使 处 理 速 度 变 平滑 ， 从 而 不 会 因 瞬 间 压 力 太 大 而 压 垮 应 用 。 


业务 系统 


通过 缓冲 区 队列 可 以 实现 批量 处 理 、 异 步 处 理 和 平 消 流 量 。 


15.3 ”任务 队列 


使 用 任务 队列 可 以 将 一 些 不 需要 与 主线 程 同步 执行 的 任务 扔 到 任务 队列 
进行 异步 处 理 。 笔 者 用 得 最 多 的 是 线程 池 任 务 队 列 (默认 为 
LinkedBlockingQueue) 和 Disruptor 任 务 队 列 (RingBuffer) 。 如 用 户 注 册 
完成 后 ， 将 发 送 邮 件 / 送 积分 / 送 优惠 券 任务 扔 到 任务 队列 进行 异步 处 理 ; 
刷 数据 时 ， 将 任务 扔 到 队列 异步 处 理 ， 处 理 成 功 后 再 异步 通知 用 户 。 还 
有 删除 SKU 操 作 ， 在 用 户 请 求 时 直接 将 任务 分 解 并 扔 到 队列 进行 异步 处 
理 ， 处 理 成 功 后 异步 通知 用 户 。 以 及 查询 聚合 时 ， 将 多 个 可 并 行 处 理 的 
任务 扔 到 队列 ， 然 后 等 待 最 慢 的 一 个 任务 返回 。 


通过 任务 队列 可 以 实现 异步 处 理 、 任 务 分 解 /聚合 处 理 。 


it: JDK7 提 供 了 ExecutorService 的 新 实现 ForkJoinPool， 其 提供 的 Work- 
stealing 机 制 ， 可 以 更 好 地 提升 并 发 效率 。 


15.4 WENZI 


笔者 所 在 公司 使 用 的 系统 是 目 主 研发 的 JMQ; 开源 的 系统 有 ActiveMQ、 
Kafka、Redis。 使 用 消息 队列 存储 各 业务 数据 ， 其 他 系统 根据 需要 订阅 即 
可 。 管 见 的 订阅 模式 是 ， 后 对 点 〈 一 个 消息 只 有 一 个 消费 者 ) 、 发 布 订 
bi] (一 个 消息 可 以 有 多 个 消费 者 ) 。 而 常用 的 是 发 布 订阅 模式 。 


比如 ， 修 改 商 品 数据 、 变 更 订单 状态 时 ， 都 应 该 将 变更 信息 发 送 到 消 忆 
队列 ， 如 采 其 他 系统 有 需要 ， 则 直接 订阅 该 消 轧 队列 即 可 。 


一 般 我 们 会 在 应 用 系统 中 采用 双 写 模式 ， 同 时 写 DB 和 MQ， 然 后 异 构 系 
统 可 以 订阅 MQ 进行 业务 处 理 (DU RED) 。 因 为 在 双 写 模式 下 没有 事务 保 
证 ， 所 以 会 出 现 数据 不 一 致 的 情况 ， 如 采 对 一 致 性 要 求 没 那么 严格 ， 则 
这 种 模式 古 没 问 题 的 ， 而 且 在 实际 应 用 中 这 种 模式 也 非常 多 。 


| 生产 系统 | 
DB 
ME 
A 
异 构 数据 

| | | 
| DB | MQ Wa Zum sU | 
| | 


如 下 代码 是 双 写 示例 ， 事 务 成 功 后 发 MQ 。 


public OrderDTO create(final OrderDTO order) throws OrderException { 

OrderDTO createdOrderDTO = executeInShardingTrans((status) -> ( 
// 插 入 订单 到 DB 
OrderDTO insertOrderDTO = convert (orderService.insert (order) ); 
return insertOrderDTO; 

}, order); 

// 发 MO 

orderMqProducer.publish(OrderMqType.CREATED, null, insertOrderDTO); 

// 写 缓存 

orderCache.put (createdOrderDTO); 

return createdOrderDTO; 


) 


如 果 在 事务 中 发 MQ， 会 存在 事务 回 深 ， 但 是 MQ 发 送 成 功 了 ， 则 需要 消 
居 消 费 者 进行 盎 等 处 理 。 如 来 事务 提交 慢 ， 但 是 MQ 已 经 发 出 去 了 ， 则 此 
时 根据 MQ 信息 再 去 获取 数据 库 数据 可 能 不 是 最 新 的 。 如 果 MQ 发 送 慢 ， 
则 会 导致 事务 无 法 快速 提交 ， 造 成 数据 库 堵塞 。 同 样 不 要 在 事务 中 掺 杂 
RPC 调 用 ，RPC 服 务 不 稳定 ， 同 样 会 引起 数据 库 阻塞 。 


也 可 以 采用 订阅 数据 库 日 志 机 制 来 实现 数据 库 变更 捕获 ， 这 样 生产 系统 
只 需要 单 写 DB， 然 后 通过 如 Canal 订 阅 数据 库 binlog 实 现 数据 库 数据 变更 
捕获 ， 然 后 业务 端 订阅 Canal 进 行业 务 处 理 。 这 种 方式 可 以 保证 一 致 性 。 


WsQL nan ru 
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15.5 ”请 求 队列 


请 求 队列 是 指 类 似 在 Web 环 境 下 对 用 户 请 求 排 队 ， 从 而 进行 一 些 特殊 控 
制 : 流量 控制 、 请 求 分 级 、 请 求 隔离 。 例 如 将 请 求 按 照 功能 划分 到 不 同 
的 队列 ， 从 而 使 得 不 同 的 队列 出 现 问题 后 相互 不 影响 。 还 可 以 对 请 求 分 
级 ， 一 些 重要 的 请 求 可 以 优先 处 理 (发 展 到 一 定 程 度 应 将 功能 物理 分 
B) 。 另 外 ， 服 务 器 处 理 能 力 有 限 ， 在 接近 服务 器 瓶颈 时 需要 考虑 限 
eP HUGUES a USQUE 
a Fil o 

如 下 图 所 示 ， 这 里 使 用 请 求 队列 来 实现 漏斗 模式 ， 对 请 求 进行 排队 、 过 
滤 、 限 流 ， 经 过 这 些 步 又 后 ， 流 入 业务 系统 的 流量 就 非常 小 了 ， 这 样 业 
务 系统 就 不 会 被 突 发 的 大 量 请 求 搞 垮 。 队 列 限 流 可 以 通过 队列 大 小 CA 
果 队 列 满 了 ， 就 抛弃 新 的 请 求 ) 和 排队 超时 (队列 里 的 请 求 很 长 时 间 没 
被 处 理 ) 实现 ， 如 果 失 败 了 ， 则 返回 让 客户 重新 排队 或 者 重 试 。 使 用 这 
i 
前 端 入 口 。 


失败 
队列 限 流 =z) 
风 控 过 滤 —2 
限 流 一 一 3; 
成 功 
v 


业务 


zs 
RR 


15.6 ”数据 总 线 队 列 


一 般 消息 队列 中 的 消息 都 是 业务 维度 的 简单 数据 ， 如 业务 键 或 业务 状 
态 。 在 商品 信息 变更 场景 中 ， 当 SKU 信 息 变 更 了 ， 只 下 发 一 个 SKU ID, 
订阅 者 需要 再 查 一 过 商品 系统 来 获取 最 新 的 变更 数据 ， 进 行 如 商品 信息 
缓存 同步 。 所 以 使 用 现 有 的 消息 队列 方式 很 难 只 进行 变更 部 分 的 推送 并 
保证 数据 的 有 序 性 。 而 此 种 场景 比较 适合 使 用 数据 总 线 队列 实现 。 例 如 
数据 库 变 更 后 需要 同步 数据 到 缓存 ， 或 者 需要 将 一 个 机 房 的 数据 同步 到 
另 一 个 机 房 ， 只 是 数据 维度 的 同步 ， 此 时 应 该 使 用 数据 总 线 队 列 ， 如 阿 
Hi Canal ^ LinkedIn 的 databus。 使 用 数据 总 线 队 列 的 好 处 是 ， 可 以 保证 
数据 的 有 序 性 。 阿 里 的 otter 是 基于 Canal 的 一 款 分 布 式 数据 库 同 步 系统 ， 
如 果 想 实时 进行 多 机 房 、 多 数据 库 数据 增 量 同步 ， 则 可 以 使 用 otter。 如 果 
需要 全 量 离线 数据 同步 ， 则 可 以 使 用 kettle 。 


可 以 通过 otter 订 阅 某 个 DB 的 某 些 表 ， 然 后 同步 到 另 一 个 数据 库 中 。 如 采 
系统 中 存在 一 些 基础 数据 ， 则 可 以 使 用 这 种 方式 进行 同步 〈 见 下 图 ) 。 


DB1 it~ otter 上 同步 DB2 


15.7 混合 队列 
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此 处 MQ 是 使 用 京东 上 自主 研发 的 JMQ， 消 息 是 可 靠 持 久 化 存储 的 。 应 用 会 
按照 不 同 的 维度 发 布 消息 到 JMQ。 下 游 应 用 接收 到 该 消息 后 会 将 其 放 入 
Redis 中 ， 使 用 Redis List 来 存储 这 些 任 务 。 应 用 将 Redis 消 息 消 费 处 理 后 ， 
会 按照 不 同 的 维度 聚合 商品 消息 ， 然 后 再 次 发 送出 去 。 


使 用 Redis 队 列 的 主要 原因 古 想 提升 消息 堆积 能 力 和 并 发 处 理 能 力 。 男 
外 ， 在 使 用 Redis 构 建 消 息 队 列 时 ， 需 要 考虑 因 网 络 抖动 造成 的 消息 丢失 
问题 ， 因 为 Redis 是 没有 事务 回 滚 的 ， 或 者 说 是 没有 确认 机 制 的 。 我 们 使 
用 如 下 方式 防止 消息 丢失 。 


try { 
id = queueRedis.opsForList() 
.rightPopAndLeftPush (queueName, processingQueueName) ; 
} catch (Exception e) { 
// 发 生 了 网 络 异 常 ， 需 要 把 processing 中 的 id 再 放 回 到 waiting queue 中 
String msg = 


queueName +" to " +processingQueueName + " rpplpush error"; 
LOG.error(msg, e); 
// 报 警 代码 
} 


而 对 于 失败 我 们 会 进行 三 次 重 试 ， 重 试 失 败 后 放 入 失败 队列 ， 而 失败 队 
列 是 c BAY 《从 本 地 队列 和 失败 队列 排 重 ) ， 这 里 使 用 Redis 
Lua 实现 。 


static EventQueueScript ADD TO FAIL QUEUE REDIS SCRIPT = 
new EventQueueScript( 
"redis.call('lrem', KEYS[1], 1, ARGV[1]) redis.call('lrem', 
KEYS[2], 1, ARGV[1]) return redis.call('lpush', KEYS[2], ARGV[1])" 
); 


Redis 的 作者 Antirez 开 发 的 内 存 分 布 式 消息 队列 Disque， 是 未 来 更 好 的 内 
存 消息 队列 选择 。 


15.8 ”其 他 队列 


` 优先 级 队列 ， 在 实际 开发 时 肯定 有 些 任务 是 紧急 的 ， 此 时 应 该 优先 处 理 
紧急 任务 。 所 以 请 考虑 对 队列 进行 分 级 。 


` 副本 队列 : 在 进行 一 些 系 统 重 构 或 者 上 新 的 功能 时 ， 如 果 没 有 足够 的 信 
心 保证 业务 逻辑 正确 ， 则 可 以 考虑 存储 一 份 队列 的 副本 (比如 1 小 时 、1 
天 的 消息 ， 从 而 当 业 务 出 现 问 题 时 ， 可 以 对 这 些 消息 进行 回放 。 


` 镜像 队列 : 每 个 队列 不 可 能 无 限制 被 订阅 消费 ， 会 有 一 个 订阅 量 极限 。 
当 达 到 极限 时 ， 请 考虑 使 用 镜像 队列 方式 解决 该 问题 。 


. 队列 并 发 数 ， 不 同 队 列 实现 ， 队 列 服务 器 端 并 发 连接 数 是 不 一 样 的 。 一 

定 不 是 增 大 队列 并 发 连接 数 消费 能 力也 随 着 增加 ， 也 不 会 因为 增加 了 消 

费 服 务 器 消费 ， 关 发 能 力也 随 之 增加 ， 逢 要 根据 实际 情况 来 设置 合理 的 
连接 数 。 


推送 拉 取 : 消息 体内 容 不 是 越 全 越 好 ， 需 要 根据 具体 业务 设计 消息 体 。 
如 有 些 系 统 依赖 商品 变更 消息 (只 有 一 个 SKU) ， 有 些 系统 依赖 商品 状 
态 消息 (SKU > RAS) ， 有 些 系统 依赖 商品 属性 变更 消息 (SKU、 变 更 
的 属性 ) 等 。 如 条 让 所 有 系统 都 消费 商品 变更 消 电 ， 那 么 这 些 系统 都 会 
调用 商品 查询 服务 ， 拉 取 最 新 商品 信息 ， 然 后 进行 处 理 。 因 此 ， 要 根据 
实际 情况 来 决定 是 使 用 推送 方式 (将 系统 需要 的 所 有 信息 推 过 去 ) 还 是 
使 用 拉 取 方式 《只 推送 ID ， 然 后 再 查 一 遍 ) 。 


15.9 ”Disruptor+Redis 队 列 
15.9.1 简介 


Disruptor 是 LMAX 开 源 的 一 个 高 性 能 异步 处 理 框 架 ， 


它 提 供 了 高 性 能 无 锁 


内 存 队 列 实现 ， 并 优化 了 CPU 伪 共 京 ， 用 于 构建 低 延 迟 高 吞吐 量 的 交易 
型 应 用 。 使 用 Disruptor 也 可 以 构建 复杂 的 任务 工作 流 ， 如 下 图 所 示 ， 这 里 


实现 消费 者 工作 流 。 


Disruptor AS 消费 者 1 
ab S ^ We ll 
[are | = T— ps L—9, 消费 者 4 
UN / / 2. 消费 
< ales > T 
= jt 
在 实际 项 目 中 ， 我 们 使 用 Disruptor 配 合 Redis 来 异步 处 理 任务 ， 整 体 架 构 
如 下 图 所 示 。 
Red 
; watt dia | uc 
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- Redis 队 列 : 我 们 使 用 Redis List 数 据 结构 来 存储 任务 ， 并 分 为 等 待 队 
列 、 本 地 处 理 队 列 、 失 败 队列 、 备 份 队 列 。 任 务 会 衣 移 发 布 到 等 竺 队 
列 ， 然 后 会 转移 到 本 地 处 理 队列 进行 处 理 ， 处 理 成 功 后 会 被 从 本 地 处 理 
队列 中 移 除 ， 如 有 果 处 理 失 败 了 ， 则 会 被 移 到 失败 队列 等 每 人 工 介 入 。 备 
份 队列 也 叫 作 镜 像 队 列 ， 当 遇 到 问题 时 ， 可 以 进行 任务 回放 。 我 们 使 用 
Redis 最 高 时 有 2 亿 多 个 任务 在 等 待 队 列 中 等 竺 处 理 。Redis 队 列 中 的 任务 
可 以 是 其 他 系统 推送 的 ， 或 者 是 MQ 推 送 的 。 


-EventQueue: 业务 组 件 ， 封 装 了 Redis 队 列 的 访问 。 
-EventPublishThread : 业务 组 件 ， 通 过 EventQueue 拉 取 Redis Wait Queue 


任务 ， 首 先 被 移动 到 Local Processing Queue, ， 然 后 被 放 入 Disruptor 
RingBuffer 内 存 队 列 处 理 。 


: RingBuffer : Disruptor 组 件 ， 一 个 环形 队列 ， 使 用 定 长 数组 存储 ， 并 预 
先 填充 好 任务 /事件 ， 不 需要 像 链 表 那 样 每 次 添加 /删除 节点 时 去 创建 /回收 
节操 ， 从 而 避免 一 定 的 垃圾 回收 。 环 形 队 列 数组 长 度 是 2^N ， 可 以 使 用 
位 运算 提升 性 能 。 整 个 队列 使 用 无 锁 设计 从 而 减少 了 竞争 。 通 过 缓存 行 
填充 解决 CPU 伪 共享 问题 。 


-WorkPool: ” Disruptor 组件 ， 存 储 WorkProcessor 的 池子 ，Disruptor 将 任务 
处 理 器 放 入 WorkPool 中 ， 然 后 通过 Executor 并 发 启动 每 一 个 
WorkProcessor ° 


- WorkProceesor: ” Disruptor 组 件 ，WorkProcessor 从 RingBuffer 消 费事 件 / 
任务 ， 并 交 由 WorkHandler 处 理 。 


WorkHanler : Disruptor 组 件 ， 处 理 任 务 的 工作 者 ， 我 们 根据 任务 类 型 
委托 给 不 同 的 EventHandler 处 理 。 


` EventHandler : 业务 组 件 ， 实 际 处 理 任 务 的 组 件 ， 处 理 成 功 后， 会 通过 
EventQueue 从 Redis 本 地 处 理 队 列 移 除 。 处 理 失 败 时 ， 会 通过 EventQueue 
把 任务 放 入 到 Redis 失 败 队列 。 


D QUE INCUN (本 书 使 用 的 是 Disruptor 
3.2.1) ° 


15.9.2 ”XML 配置 
首先 是 EventQueue 配 置 。 


<bean id="productEventQueue" parent-"com.queue.EventQueue"» 
<property name="queueRedis" ref="queueRedis"/> 
<property name="processingErrorRetryCount" value="2"/> 
<property name="queueName" value="product"/> 
<property name="maxBakSize" value="20000000"/><!-- 2000w --> 
</bean> 


: queueRedis: 配置 Redis 队 列 实例 ， 我 们 使 用 jedis 客 户 端 。 


- processingErrorRetryCount : 本 地 任务 队列 中 失败 后 的 重 斌 次数 ， 当 
Disruptor 处 理 失败 时 会 进行 重 试 。 


- queueName : 我 们 使 用 的 Redis 等 待 队 列 名 称 ， 任 务 会 从 该 队列 拉 取 ， 
队列 使 用 List 数 据 结 构 实现 。 


-maxBakSize: 队列 的 镜像 大 小 ， 当 从 等 待 队 列 中 拉 取 任务 时 ， 会 放 入 
x a 从 而 当 业 务 处 理 出 现 问题 时 进行 重 放 ， 业 务实 现时 


接 下 来 是 EventHandler 配 置 。 


<bean id="productEventHandler" 
class="com.task.handler.ProductEventHandler"/> 


最 后 是 EventWorker 实 现 。 


<bean id="productEventWorker" class="com.task.EventWorker" 
init-method= "init" destroy-method-"stop"» 
<property name-"threadPoolSize" value="256"/> 
<property name="ringBufferSize" value="4096"/> 
<property name="eventHandlerMap"> 
<map> 


«entry key-ref-"productEventQueue" value-ref-" productEventHandler"/» 


</map> 
</property> 
</bean> 


业务 组 件 EventWorker: 用 于 创建 Disruptor 相 关 组 件 ， 包 含 如 下 配置 项 
目 o 


-init/stop : init 用 于 初始 化 并 启动 Disruptor 。Stop 用 于 当 JVM 终 止 时 停止 
Disruptor 组 件 。 


` ringBufferSize : 环形 队列 大 小 ， 大 小 必须 是 2 的 倍数 。 


-eventHandlerMap : 映射 EventQueue 与 EventHandler 的 关系 ， 从 特定 的 
EventQueue 中 获取 的 任务 将 被 关联 的 EventHandler 处 理 。 


15.9.3 EventWorker 


eventHandlerMap 用 于 配置 EventQueue 与 EventHandler 的 关系 。 


public void setEventHandlerMap( 

Map«EventQueue, EventHander» eventHandlerMap) { 
this.eventHandlerMap - eventHandlerMap; 
if(MapUtils.isNotEmpty(eventHandlerMap)) { 

this.eventQueueMap - Maps.newHashMap(); 
for(Map.Entry«EventQueue, EventHander> entry : 
eventHandlerMap.entrySet()) { 


EventQueue queue = entry.getKey(); 
this.eventQueueMap.put (queue.getQueueName(), queue); 


} 


eventHandlerMap 存储 了 EventQueue 和 EventHandler 的 关系 。 
eventQueueMap 存 储 了 queueName 与 EventQueue 的 关系 。 


init 


W) 48 44, Disruptor ^ WorkHandler ^ EventHandler ^ EventPublishThread = 28, 
件 ， 并 局 动 Disruptor、EventPublishThread 。 


public void init() throws Exception { 

//1. 创建 Disruptor 

disruptor = new Disruptor<Event> ( 
new DefaultEventFactory()，// 使 用 默认 事件 工厂 
ringBufferSize, //RingBuffer 大 小 
Executors.newFixedThreadPool (threadPoolSize)，// 消 费 者 线程 池 
ProducerType.MULTI, // 支 持 多 事件 发 布 者 
new BlockingWaitStrategy()); // 阻 塞 等 待 策略 

//2. 获取 RingBuffer 

ringBuffer = disruptor.getRingBuffer(); 

/[3. 处 理 异常 


disruptor.handleExceptionsWith (new ExceptionHandler() { 


//4. 创建 工作 者 处 理 器 
WorkHandler<Event> workHandler = new WorkHandler<Event>() { 
@Override 
public void onEvent (Event event) throws Exception { 
String type = event.getEventType(); 
//4.1 根 据 事 件 类 型 获取 Event Queue 
EventQueue queue = eventQueueMap.get (type) ; 
//4.2 根据 EventQueue 获取 该 队列 的 事件 处 理 器 (xML 中 配置 了 关心 ) 
EventHander hander = eventHandlerMap.get (queue); 
//4.3 交 由 EventHandler 处 理 该 事件 
hander.onEvent(event.getKey(), type, queue); 
} 
E 
//5.1 创建 工作 者 处 理 器 (数量 为 线程 池 大 小 ) 
WorkHandler[] workerHanders = new WorkHandler[threadPoolSize]; 
for (int i = 0; i < threadPoolSize; i++) { 
workerHanders[i] = workHandler; 


} 
//5.2 4A Disruptor 由 工作 者 处 理 器 处 理 


disruptor.handleEventsWithWorkerPool (workerHanders); 
//6. 局 动 Disruptor 
disruptor.start(); 
//1. 启动 发 布 者 线程 (BS EventQueue 一 个 ， 可 以 优化 为 只 有 一 个 ) 
for (Map.Entry<String, EventQueue> eventQueueEntry : 
eventQueueMap.entrySet()) { 
String eventType = eventQueueEntry.getKey(); 
EventQueue eventQueue = eventQueueEntry.getValue(); 
// 每 个 类 型 的 队列 创建 一 个 发 布 者 
EventPublishThread thread = 
new EventPublishThread(eventType, eventQueue, ringBuffer); 
eventPublishThreads.add (thread); 
thread.start(); 


) 


此 处 我 们 配置 的 Disruptor 文 持 多 发 布 者 ， 当 RingBuffer 满 时 使 用 阻塞 等 待 
策略 。WorkHandler 会 将 Event 交 给 相应 的 EventHandler 处 理 。 


当 JVM 停 止 时 ， 需 要 停止 Disruptor 和 EventPublishThread ° 


public void stop () { 
//1. 停止 发 布 者 线程 
for(EventPublishThread thread : eventPublishThreads) { 
thread.shutdown(); 
} 
//2. t#iE Disruptor 
disruptor. shutdown () ; 


15.9.4 EventPublishThread 


public void run() { 
while (running) {// 当 调用 shutdown 方法 时 ， 设 置 为 false 即 可 
String nextKey = null; 
try { 
if(nextKey == null) {// 从 Eventoueue 获取 下 一 个 任务 
nextKey = eventQueue.next(); 
} 
if(nextKey != null) {// 发 布 到 RingBuffer 
ringBuffer.publishEvent( 
EVENT TRANSLATOR, nextKey, eventType); 
} 
} catch (Exception e) { 
logError(nextKey, e); 


) 


EventPublishThread 实 现 比较 简单 ，eventQueueffmext 方 法 将 从 Redis 等 待 队 
列 POP 一 个 任务 ， 然 后 推送 到 本 地 任务 队列 (该 队列 名 称 是 : queueName 
+ JVM 实 例 所 在 机 器 IP) ， 并 发 布 到 Disruptor RingBuffer 。 


EVENT TRANSLATOR 用 于 将 参数 转化 为 Disruptor 的 Event 对 象 。 


public void translateTo(Event event, long sequence, String key, String 
eventType) { 
event.setKey (key) ; 
event.setEventType (eventType); 
) 


15.9.5 EventHandler 


以 我 们 的 ProductEventHandler 为 例 ，key 就 是 有 变更 的 skuld， 我 们 根据 
skuld 拉 取 最 新 的 变更 内 容 ， 然 后 更 靳 到 线 上 异 构 集群 ， 如 果 成 功 ， 则 从 
本 地 任务 队列 删除 任务 。 如 果 失 败 ， 则 将 重 斌 或 者 推送 到 失败 队列 。 


public void onEvent(String skuId, String eventType, EventQueue queue) { 
try { 
// 将 skuId 最 新 的 变更 内 容 更 新 到 线 上 异 构 数据 集群 
queue.success (SkuId) ; 
) catch (Exception e) ( 
queue.fail(skuId); 
) 
) 


至 此 ， 涉 及 任务 处 理 的 内 容 就 都 介绍 完了 ， 使 用 Disruptor 可 以 快速 构建 一 
套 内 存 任 务 处 理 逻 辑 。 接 下 来 我 们 来 看 一 下 EventQueue 的 实现 。 


15.9.6 EventQueue 
1.next 方 法 


public String next() throws Exception { 
while (true) { 
//1. HH Queue 消费 


PauseUtils.pauseQueue (queueName) ; 


String id - null; 


try { 

//2. 从 等 待 Queue POP， 然 后 PUSH 到 本 地 处 理 队 列 

id = queueRedis.opsForList () 

.rightPopAndLeftPush(queueName, processingQueueName) ; 

} catch (Exception e) { 

//3. RES Meu, NEA Lave wea, 

// 将 本 地 任务 队列 长 时 间 未 消费 的 任务 推送 回 等 待 队列 

continue; 


} 


//4. 返回 获取 的 任务 
if (id != null) { 
awaitInMillis = DEFAULT AWAIT IN MILLIS; 
return id; 
} 
lock. lock(); 
try { 
// 如 果 没 有 任务 ， 则 休息 一 下 稍 后 处 理 ， 防 止 死 循环 耗 死 CPU 
if (awaitInMillis < 1000) { 
awaitInMillis = awaitInMillis + awaitInMillis; 
) 
notEmpty.await (awaitInMillis, TimeUnit.MILLISECONDS); 
} catch (Exception e) { 
//ignore 
} finally { 
lock.unlock(); 
) 


) 


next 用 于 从 Redis 等 待 队列 获取 任务 并 推送 到 本 地 处 理 队 列 ， 然 后 返回 此 
任务 。 放 入 本 地 处 理 队 列 使 用 了 rightPopAndLeftPush， 目 的 是 防止 因为 网 
络 异 常 导致 任务 丢失 (因为 Redis 本 身 是 没有 事务 的 ) ， 当 发 生 网 络 异常 
时 需要 告警 ， 然 后 人 工 介 入 处 理 ， 或 者 启动 一 个 Worker 定 期 检查 队列 内 
容 是 否 长 时 间 未 消费 ， 如 果 长 时 间 未 消费 ， 则 应 该 再 转移 回 等 待 队列 处 
理 。 如 果 队 列 中 没有 任务 ， 则 应 该 短暂 休息 一 会 儿 ， 然 后 重 试 ， 不 要 造 
成 死 循环 耗 死 CPU 。 


2.success 方 法 


public void success(String id) { 
queueRedis.opsForList().remove(processingQueueName, 0, id); 


} 


当 任务 成 功 处 理 后 ， 从 本 地 任务 队列 移 除 该 任务 。 
3.fail 方 法 


public void fail(final String id) { 
final int failedCount - 
failedCache.getUnchecked(id).incrementAndGet(); 
if (failedCount < processingErrorRetryCount) { 
// 如 果 小 于 重 试 次 数 ， 则 直接 添加 到 等 待 队 列 尾 
ADD TO BACK REDIS SCRIPT.exec(queueRedis, Lists.newArrayList 
(processingQueueName, queueName), id); 
) else {// 如 果 超 过 失败 重 试 次 数 ， 则 加 入 失败 队列 
ADD TO FAIL QUEUE REDIS SCRIPT.exec(queueRedis, Lists.newArrayList 
(processingQueueName, failedQueueName), id); 


} 


} 
fail 方 法 根据 失败 重 试 次 数 决 定 是 放 入 等 待 队列 重 试 ， 还 是 超过 了 失败 重 
试 次数 直接 转移 到 失败 队列 ， 然 后 告警 ， 人 工 介 入 处 理 。 
4.enqueueToBack 方 法 


该 方法 用 于 接收 其 他 系统 推送 的 任务 ， 比 如 接收 MQ 消 思 ， 然 后 入 队 到 
Redis 等 竺 队列。 其 核心 实现 是 通过 Redis Lua 脚 本 将 任务 加 入 队列 ， 在 加 
入 队列 时 需要 同时 镜像 一 份 放 入 到 备份 队列 。 


ENQUEUE TO LEFT REDIS SCRIPT.exec(queueRedis, Lists.newArrayList (queueName, 
id, makeBakQueueName(), maxBakSizeStr)); 


这 里 用 ENQUEUE_TO_LEFT_REDIS_SCRIPT 实 现 Lua 脚 本 。 


static EventQueueScript ENQUEUE TO LEFT REDIS SCRIPT = new EventQueueScript ( 

" local remCount = 0 if redis.call('llen', KEYS[1]) < 10000 then 
remCount = redis.call('lrem', KEYS[1], 1, KEYS[2]) end redis.call('lpush', 
KEYS[ll, KBYS[2]) " + 

" if tonumber(KEYS[4]) <=0 then return nil end " + 

" if remCount > 0 then return nil end " 十 

"local len = redis.call('llen', KEYS[3]) " + 

" if len > tonumber(KEYS[4]) then redis.call('lpop', KEYS[3]) end 
redis.call('rpush', KEYS[3], KEYS[2]) " 

); 


如 果 等 待 队 列 数 量 小 于 10000， 则 会 进行 排 重 (通过 lrem 先 删除 ， 然 后 再 
通过 lpush 进 行 重 排 ) 。 如 果 等 待 队列 数量 大 于 10000， 因 为 志 历 List 性 能 
会 变 得 很 差 ， 则 此 时 不 会 进行 排 重 。 数 据 同 时 会 被 放 入 备份 队列 ， 当 备 
份 队 列 满 了 时 ， 使 用 FIFO 移 除 最 先 插入 的 任务 。 


5. 队 列 名 称 
-queueName: 即 等 待 队列 名 称 ， 在 XML 配置 文件 中 配置 了 。 


* procesingQueueName : 本 地 处 理 队 列 名 为 queueName + 
* processing queue ”+ locallp ° 


: failedQueueName: 失败 队列 名 为 queueName + * failed queue" ° 


: bakQueueName : 备份 队列 名 为 queueName + "bak queue ”+ 
LocalTime.now (.getHour()， 一 个 小 时 一 个 队列 ， 这 样 一 天 就 有 24 个 备份 
队列 。 


至 此 ， 整 个 Disruptor+Redis 实 现 的 队列 及 任务 处 理 逻 辑 束 介绍 完了 ， 本 章 
的 示例 实现 并 不 完美 ， 还 有 很 多 优化 空间 ， 尤 其 在 排 重 、 任 务 调度 、 自 
动 化 、 可 靠 性 等 方面 还 可 以 优化 得 更 好 。 


使 用 Redis 会 存在 丢 任 务 的 风险 ， 要 根据 实际 业务 来 决定 是 否 允 许 丢 任 
务 ， 实 际 上 大 多 数 业 务 只 要 保证 尽量 不 丢 即 可 ， 不 需要 保证 百分之百 不 
和 于， 实现 百分之百 不 于 是 非常 难 的 。 保 证 业务 逻辑 一 定 是 正确 的 更 重 
要 ， 一 旦 业务 逻辑 写 错 了 ， 就 要 想 办 法 进行 数据 回 深 ， 此 时 备份 队列 的 
数据 束 很 有 作用 了， 尤其 是 在 重 构 或 者 有 新 的 逻辑 时 。 


Redis 作 者 还 写 了 一 个 内 存 分 布 式 消 轧 任 务 队 列 Disdque， Disque 使 用 确认 
机 制 保证 消息 可 靠 ， 目 前 只 有 Beta 版 本 ， 不 过 截至 目前 已 经 快 一 年 未 更 新 
Te 


15.10 下 单 系统 水 平 可 扩展 架构 


订单 系统 是 交易 型 网 站 的 核心 之 一 ， 用 户 会 在 这 类 网 站 上 浏览 并 购买 商 
品 ， 购 买 后 束 会 产生 订单 ， 接 着 需要 用 户 进 行 支付 ， 文 付 成 功 后 束 进 入 
生产 流程 。 而 这 其 中 最 重要 的 一 步 束 是 能 让 用 户 先 下 单 并 成 功 文 付 ， 而 
后 续 流 程 可 以 不 用 实时 处 理 。 因 此 ， 如 何 保证 下 单 功能 的 高 性 能 和 高 可 
用 是 一 个 交易 型 网 站 的 核心 之 一 ， 当 然 这 对 于 其 他 系统 也 同等 重要 。 


一 般 订单 系统 会 进行 分 库 分 表 ， 如 采 分 库 分 表 的 数量 不 够 ， 则 会 影响 到 
系统 的 性 能 ， 一 般 通过 扩容 来 解决 。 或 者 当 同 一 个 订单 库 被 多 个 系统 依 
赖 ， 其 中 某 个 系统 有 慢 操 作 时 ， 以 及 当 一 次 下 单 需 要 写 很 多 表 并 且 订 单 
量 较 大 时 ， 这 都 会 造成 用 户 下 单 速 度 变 慢 ， 甚 至 无 法 下 单 。 因 此 需要 一 
种 方案 来 解决 这 个 问题 。 第 15 革 介绍 过 缓冲 队列 ， 如 果 把 订单 放 入 缓冲 
队列 ， 然 后 能 迅速 同步 到 订单 中 心 ， 那么 就 可 以 把 下 单 逻辑 和 操作 订单 
逻辑 分 开 ， 用 户 下 单 只 操作 缓冲 表 ， 而 操作 订单 只 操作 订单 表 ， 从 而 在 
操作 订单 表 时 不 会 影响 到 缓冲 表 。 而 且 绥 冲 表 可 以 通过 水 平 扩容 来 支持 
更 大 请 求 。 下 图 是 我 们 的 订单 系统 的 整体 架构 。 


2.1 插 入 Order 到 Buffer DB 
根据 ID 放 入 不 同 的 DB 


2.3 "Buffer DB 故障 时 降级 直接 写 订单 中 心 


g 3 轮 询 Order Buffer 同 步 Worker 4.1 同步 到 订单 中 心 
4.2 删除 Order Buffe 


整体 流程 介绍 如 下 。 


1. 首 先 ， 用 户 在 结算 页 提 区 订单 后 ， 系 统 调用 订单 号 生成 服务 ， 然 后 结算 
服务 会 进行 一 些 业 务 处 理 ， 最 后 调用 下 单 服务 提交 订单 。 


2. 下 单 服 务 将 订单 写 入 订单 缓冲 表 ， 下 单 服务 和 订单 缓存 表 可 以 水 平 扩 
展 ， 从 而 文 持 更 多 的 下 单 操作 。 写 入 缓冲 表 成 功 后 ， 将 订单 写 入 缓存 ， 
从 而 前 端 用 户 可 以 查看 到 当前 订单 。 如 采 下 单 服 务 有 问题 ， 则 可 以 考虑 
直接 降级 将 订单 写 入 订单 中 心 。 


3. 接 着 绥 冲 同步 Worker 轮 询 这 些 缓冲 表 。 


4. 同 步 Worker 将 订单 同步 到 订单 中 心 ， 如 果 订单 中 心 数据 有 变更 ， 则 更 新 
订单 缓存 。 


15.10.1 下 单 服 务 


public void submitOrder(OrderDTO order) { 
RoundRobinTable.Table table = roundRobinTable.nextTable(); 
String sql = getsql (table); 
JdbcTemplate template = new JdbcTemplate (table.getDataSource()); 
Long orderId = order.getId(); 


String orderJson = JSONUtils.toJSON(order); 
template.update(sql, orderId, orderJson); 
// 放 入 缓存 


orderCache.put (order); 


) 


RoundRobinTable 征 轮 询 选 择 下 一 个 要 写 入 的 表 ， 然 后 将 数据 写 入 到 缓冲 
表 ， 写 入 成 功 后 再 写 入 缓存 。 


此 处 的 缓冲 表 结 构 可 以 包括 : 订单 ID、 订 单 JSON 串 、 订 单 状态 、 创 建 时 
间 、 处 理 状态 、 重 试 次 数 和 WorkerIP。 


缓冲 表 所 在 的 宿主 机 如 也 可 能 会 出 现 硬 件 故 障 ， 当 出 现 问题 时 ， E 


影响 部 分 订单 的 同步 ， 不 影响 支付 (因为 缓存 里 有 一 份 订单 数据 ) 
性 能 遇 到 瓶 倾 时 ， 可 以 通过 水 平 扩容 更 多 的 缓冲 表 来 解决 。 


15.10.2 ”同步 Worker 


E 的 同步 Worker 也 用 到 了 Disruptor 架 构 ， 只 是 队列 使 用 了 数据 库 缓冲 表 
实现 。 


1.OrderBufferPublishThread 


批量 查询 缓冲 表 并 发 布 到 Disruptor RingBuffer 中 。 


Map<RoundRobinTable.Table, Long» lastIdMap = Maps.newHashMap(); 
Map«RoundRobinTable.Table, Object» lastOrderIdMap = Maps.newHashMap(); 
while(running) { 
RoundRobinTable.Table table = roundRobinTable.nextTable(); 
// 批 量 查 询 缓冲 表 〈 把 处 理 状 态 改 成 “处 理 中 ”并 将 WorkerIp 设置 为 当前 JVM IP) 
List<Map<String, Object>> list = 
listOrderBuffers (table, lastIdMap.get (table)); 
// 循 环 发 布 缓冲 订单 
list.forEach((map) => { 
Long id = (Long)map.get ("id"); 
Long orderId = (Long)map.get ("order id"); 
String orderJson = (String)map.get ("order _json") ; 
publishEvent (table, id, orderId, orderJson) ; 
lastIdMap.put (table, id); 
lastOrderIdMap.put (table, orderId); 
tryRateLimit () ;// 是 否 限 流 


2.OrderBufferHandler 
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Long orderId = orderBufferEvent.getOrderId(); 
String orderJson = orderBufferEvent.getOrderJson(); 
RoundRobinTable.Table table = orderBufferEvent.getTable(); 
try { 
//1. 同步 缓冲 订单 到 订单 中 心 
OrderDTO order = JSONUtils.fromJson(orderJson, OrderDTO.class); 
orderJsfService.save (order); 
//2. 操作 成 功 删 除 缓冲 订单 
deleteOrderBuffer(table, orderId); 
} catch (OrderException e) { 
//3. 如 果 遇 到 异常 ， 则 首先 判断 是 否 已 经 插入 数据 库 ， 如 果 是 ， 则 直接 删除 缓冲 订单 即 可 
OrderDTO order = orderJsfService.getOrderFromDB (orderId); 
if (order != null) { 
// 已 经 成 功 插入 数据 库 
deleteOrderBuffer(table, orderId); 


} 
} 


至 此 ， 一 个 简单 的 数据 库 订 单 缓冲 架构 就 实现 了 ， 在 实际 生产 环境 中 还 
需要 进行 健壮 性 设计 ， 比 如 ，Worker 多 实例 部 署 、Worker 不 可 用 之 后 如 
何 把 它 处 理 的 订单 快速 恢复 、 缓 存 库 不 可 用 后 的 降级 处 理 、 订 单 号 生成 
服务 如 何 高 可 用 等 。 


15.11 基于 Canal 实 现 数据 异 构 


在 大 型 网 站 架构 中 ，DB 都 会 采用 分 库 分 表 来 解决 容量 和 性 能 问题 ， 但 是 
分 库 分 表 之 后 市 来 了 新 的 问题 ， 比 如 不 同 维度 的 查询 或 者 聚合 查询 ， 此 
时 就 会 非常 环 手 。 一 般 我 们 会 通过 数据 异 构 机 制 来 解决 此 问题 。 


如 下 图 所 示 ， 为 了 提升 系统 的 接 单 能 力 ， 我 们 会 对 订单 表 进 行 分 库 分 
表 ， 但 是 ， 随 之 而 来 的 问题 是 : 用户 怎 么 查询 自己 的 订单 列表 呢 ? 一 种 
办 法 扫描 所 有 的 订单 表 ， 然 后 进行 聚合 ， 但 是 这 种 方式 在 大 流量 系统 
以 构 中 肯定 是 不 行 的 。 另 一 种 办 法 是 双 写 ， 但 是 双 写 的 一 致 性 又 没 法 保 
证 。 还 有 一 种 办 法 束 是 订阅 数据 库 变 更 日 志 ， 比 如 订阅 MySQL 的 binlog 日 
志 模 拟 数据 库 的 主 从 同步 机 制 ， 然 后 解析 变更 日 志 将 数据 写 到 订单 列 
表 ， 从 而 实现 数据 异 构 ， 这 种 机 制 也 能 保证 数据 的 一 致 性 。 


订单 中 心 按 照 订 单 号 分 库 分 表 


a [e] 


订单 列表 按照 用 户 分 库 分 表 


db user order 1 db user order 2 


除了 可 以 进行 订单 列表 的 异 构 ， 像 商家 维度 的 异 构 、ES 搜 索 异 构 、 订 单 
缓存 异 构 等 都 可 以 通过 这 种 方式 解决 。 

在 介绍 Canal 之 前 ， 我 们 先 看 一 下 MySQL 的 主 从 复制 架构 。 

15.11.1 MySQL 主 从 复制 


MySQL 主 从 复制 架构 如 下 图 所 示 。 


binlog 


relay log 


1. 首 移 MySQL 客 户 端 将 数据 写 入 master 数 据 库 。 
2.master 数 据 库 会 将 变更 的 记录 数据 写 入 二 进 制 日 志 中 ， 即 binlog。 


3.slave 数 据 库 会 订阅 master 数 据 库 的 binlog 日 志 ， 通 过 一 个 IO 线程 从 
binlog 的 指定 位 置 拉 取 日 志 进 行 主 从 同步 ， 此 时 master 数 据 库 会 有 一 个 


Binlog Dump 线 程 来 读 取 binlog 日 志 与 slave IO 线程 进行 数据 同步 。 
4.slave W/O 线 程 读 取 到 日 志 后 会 和 完 写 入 relay log 重 放 日 志 中 。 


5.slave 数 据 库 会 通过 一 个 SQL 线 程 读 取 relay log 进 行 日 志 重 放 ， 这 样 就 实 
现 了 主 从 数据 库 之 间 的 同步 。 


可 以 把 Canal 看 作 slave 数 据 库 ， 其 订阅 主 数据 库 的 binlog 日 志 ， 然 后 读 取 
并 解析 日 志 ， 这 样 就 实现 了 数据 同步 / 异 构 。 


15.11.2 ”Canal 简 介 

ee ROS Pes pe 订阅 和 消费 组 
件 ， 通 过 它 可 以 订阅 数据 库 的 binlog 日 志 ， 然 后 进行 一 些 数据 消费 ， 如 数 
据 镜 像 、 数 据 异 构 、 数 据 索 引 、 缓存 更 新 等 。 相 对 于 消息 队列 ， 通过 这 
种 机 制 可 以 实现 数据 的 有 序 性 和 一 致 性 。 


Canal 架 构 如 下 图 所 示 。 
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首先 需要 部 署 canal server， 0 但 是 只 台 是 活跃 的 ， 
其 他 的 作为 备 机 。canal server 会 通过 slave 机 制订 阅 数 据 库 的 binlog 日 志 。 


canal server 的 高 可 用 是 通过 来 zk 维护 的 。 


然后 canal client 会 订阅 canal server， 消 费 变 更 的 表 数 据 ， 然 后 写 入 到 如 镜 
像 数 据 库 、 异 构 数据 库 、 绥 存 数据 库 ， 具 体 如 何 应 用 就 看 自己 的 场景 
了 ， 同 时 也 只 有 一 台 canal dient 是 活跃 的， 其 他 的 作为 备 机 ， 当 活跃 的 
canal client 不 可 用 后 ， 备 机 会 被 激活 。canal client 的 高 可 用 也 是 通过 zk 来 
维护 的 ， 比 如 zk 维护 了 当前 消费 到 的 日 志 位 置 。 


canal server 目前 读 取 的 binlog 事 件 只 存储 在 内 存 中 ， 且 只 有 一 个 canal 
client 能 进行 消费 ， 其 他 的 作为 备 机 。 如 果 需 要 多 消费 客户 端 ， 则 可 以 先 
写 入 ActiveMQ/kafka， 然 后 进行 消费 。 如 果 有 多 个 消费 者 ， 那 么 也 建议 使 
用 此 种 模式 ， 而 不 是 启动 多 个 canal server 读 取 binlog 日 志 ， 这 样 会 使 得 数 
据 库 的 压力 较 大 。ActiveMQ 提 供 了 虚拟 主题 的 概念 ， 文 持 同 一 份 内 容 多 
消费 者 镜像 消费 的 特性 。 


canal 一 个 常见 应 用 场景 是 同步 缓存 ， 当 数据 库 变 更 后 通过 binlog 进 行 缓存 


的 增 量 更 新 。 当 缓存 更 新 出 现 问 题 时 ， 应 能 回 退 binlog 到 过 去 某 个 位 置 进 
行 重 狐 同 步 ， 并 提供 全 量 刷 缓存 的 方法 ， 如 下 图 所 示 。 


全 量 同 步 
MysQL 数 据 库 ae 


1. 增 量 同步 (biglog) 


canal server canal client 增 量 更 新 


男 一 个 常见 应 用 场景 是 下 发 任务 ， 当 数据 变更 时 需要 通知 其 他 依赖 系 
统 。 其 原理 是 任务 系统 监听 数据 库 数 据 变更 ， 然 后 将 变更 的 数据 写 入 
MGQ/Kafka 进 行 任务 下 发 ， 比 如 商品 数据 变更 后 需要 通知 商品 详情 页 、 列 
表 页 、 搜 索 页 等 相关 系统 。 这 种 方式 可 以 保证 数据 下 发 的 精确 性 ， 通 过 
MQ 发 消息 通知 变更 缓存 是 无 法 做 到 这 一 点 的 ， 而 且 业 务 系统 中 也 不 会 散 
落 着 各 种 下 发 MQ 的 代码 ， 从 而 实现 了 下 发 的 归 集 ， 如 下 图 所 示 。 


Mysal 数 据 库 eni 


1. 增 量 同步 (biglog) 


2. 全 量 同步 
MyS QL 数据 库 查询 同步 


1. 增 量 同步 (biglog) 
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类 似 于 数据 库 触发 左 ， 只 要 想 在 数据 库 数 据 变 更 时 进行 一 些 处 理 ， 都 可 
以 使 用 Canal 来 完成 。 


在 MySQL 主 从 架构 中 ， 当 有 多 个 slave 连 接 master 数 据 库 时 ，master 数 据 库 
的 压力 比较 大 ， 为 保障 master 数 据 库 的 性 能 ，canal server 可 订阅 slave 的 


binlog H zs, Rllzéslavel'Jslave ° 


15.11.3 Canal i 


1. 数 据 库 配 置 
修改 my.ini 配 置 文件 的 如 下 信息 o 


任务 下 发 Worker FR] MO/kafka | 


[mysqld] 

log-bin=mysql-bin # 开 启 二 进 制 日 志 
binlog-format-ROW # 使 用 row 模 式 ， 不 要 使 用 statement 或 者 mixed 模 式 
server id-1 # 配 置 主 数据 库 ID， 不 能 和 从 数据 库 重复 

binlog 提 供 了 三 种 记录 模式 。 


(1) row: 记录 的 是 修改 的 记录 信息 ， 而 不 是 执行 的 SQL， 二 进 制 日 志 
文件 会 占用 更 大 的 空间 ， 当 执行 alter table 修 改 表 结 构造 成 记录 变更 时 ， 
该 表 的 每 一 条 记录 都 会 被 记录 到 日 志 中 。 


(2) statement: 每 一 条 修改 数据 的 SQL 都 会 被 记录 在 binlog 中 ， 其 缺点 很 
明显 ， 比 如 我 们 使 用 了 MySQL 系统 函数 ， 可 能 会 导致 主 从 数据 不 一 致 。 


(3) mixed: 一 般 SQL 使 用 statement 模 式 记 录 ， 特 殊 操作 如 一 些 系统 画 
数 ， 则 采用 row 模 式 记 录 。 


在 使 用 Canal 时 建议 使 用 row 模 式 o 


另外 ， 在 MySQL 中 执行 “show binary logs” 将 看 到 当前 有 哪些 二 进 制 日 志 
文件 及 其 大 小 。 


我 们 要 为 Canal 创 建 一 个 复制 账号 ， 并 为 其 授权 查询 和 复制 权 


CREATE USER canal IDENTIFIED BY ‘canal'; 


GRANT SELECT, REPLICATION SLAVE, ERPLICATION CLIENT ON *.* 
TO 'canal'@'%'; 
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2. 启 动 ZooKeeper 


到 zk 官网 下 载 ZooKeeper-3.4.9， 如 果 需 要 修改 zoo.cfg 配 置 文件 ， 则 进行 一 
些 配 置 ， 然 后 执行 如 下 命令 启动 单 ZooKeeper 服 务 器 。 


./bin/zkServer.sh start 


为 了 简化 演示 ， 我 们 没有 部 署 zk 集 群 。 


3.Canal Server 


到 Canal 官 网 下 载 canal.deployer-1.0.22.tar.gz ， 首 先 需 要 进行 数据 库 实例 
的 配置 ， 其 提供 了 conf/example/instance.properties 一 个 示例 配置 ， 我 们 复 
制 一 份 到 conf/product/ instance.properties， 然 后 修改 以 下 配置 。 


## mysql serverld 必须 和 master 不 一 样 


canal.instance.mysql.slaveld = 101 


# pm info ”链接 的 数据 库 地 址 和 从 哪个 二 进 制 日 志文 件 和 从 哪个 位 置 
开始 


canal.instance.master.address = 192.168.0.10:3306 
# MySQL 主 库 链 接 时 ， 起 始 的 binlog 文 件 
canal.instance.master.journal.name = 

# MySQL 主 库 链 接 时 ， 起 始 的 binlog 偏 移 量 
canal.instance.master.position = 

# MySQL 主 库 链 接 时 ， 起 始 的 binlog 的 时 间 稚 
canal.instance.master.timestamp = 


# 用 户 名 /密码 /默认 数据 库 / 数 据 库 编 码 (一 定 要 配置 正确 ) 


canal.instance.dbUsername = canal 
canal.instance.dbPassword = canal 
canal.instance.defaultDatabaseName = 


canal.instance.connectionCharset = UTF-8 
还 可 以 通过 如 下 配置 过 滤 订 阅 哪些 数据 库 中 的 哪些 表 ， 从 而 减少 不 必要 


的 订阅 ， 比 如 ， 我 们 只 关注 产品 数据 库 ， 那 么 通过 如 下 模式 即 可 只 订阅 
产品 数据 库 。 


canal.instance.filter.regex = product_\d+\\.* 


如 果 有 多 个 数据 库 可 以 进行 多 个 ***/instance.properties 配 置 ， 则 每 个 数据 
库 设置 一 个 配置 文件 。 


接 下 来 ， 进 行 canal server 的 配置 ， 修 改 conf/canal.properties ° 
#canal id、 地 址 、 端 口 和 使 用 的 zk 服务 地 址 


canal.id- 1 

canal.ip- 

canal.port- 11111 
canal.zkServers-127.0.0.1:2181 


# 当 前 canal server 上 部 署 的 实例 ， 配 置 多 个 时 用 逗号 分 隔 ， 此 处 配置 了 


product 

canal.destinations- product 

# 使 用 zk 持久 化 模式 ， 这 样 可 以 保证 集群 数据 共享 ， 文 持 HA 
canal.instance.global.spring.xml = classpath:spring/ default-instance.xml 
然后 执行 如 下 命令 ， 局 动 一 个 canal server ° 

Jbin/startup.sh 

4.Canal Client 


接着 创建 或 在 已 有 的 Java 必 用 中 添加 MySQL 客 户 端 依赖 、Canal 客 户 端 依 
WB (com.alibaba.otter# canal.client 1.0.22) ° 


订阅 数据 库 变更 的 Java 代 人 码 。 


public void test() throws Exception { 
// 通 过 zookeeper 连接 canal server 
String zkServers = "192.168.61.129:2181"; 
// 目 标 是 product 实例 
String destination = "product"; 
CanalConnector connector = 


CanalConnectors.newClusterConnector (zkServers, destination, "", ""); 


// 连 接 ， 并 订阅 product 数据 库 下 的 product 表 ( 如 果 不 写 该 模式 ， 则 订阅 所 有 的 ) 
connector.connect (); 
connector. subscribe ("product_.*\\.product_.*") ; 


while (true) { 
// 批 量 获取 1000 个 日 志 ( 不 确认 模式 ) 
Message message = connector.getWithoutAck (1000) ; 
for(Entry entry : message.getEntries()) { 


// 如 果 是 行 数据 


if(entry.getEntryType() == EntryType.ROWDATA) { 
// 则 解析 行 变更 
RowChange row = RowChange.parseFrom (entry.getStoreValue()); 
EventType rowEventType = row.getEventType(); 
for(RowData rowData : row.getRowDatasList()) { 
// 如 果 是 删除 ， 则 获取 删除 的 数据 ， 然 后 进行 业务 处 理 
if (rowEventType == EventType.DELETE) { 
List<Column> columns = rowData. getBeforeColumnsList(); 
delete (columns); 
} 
// 如 果 是 新 增 /修改 ， 则 获取 新 增 / 修 改 的 数据 进行 业务 处 理 
if (rowEventType == EventType.INSERT 
|| rowEventType -- EventType.UPDATE) ( 
List<Column> columns = 
rowData. getAfterColumnsList () ; 
Save (columns); 


} 
} 
// 确 认 日 志 消费 成 功 


connector.ack(message.getId()); 


) 


private static void save(List«Column» columns) ( 
columns.forEach((column -> { 
String name = column.getName(); 
String value = column.getValue(); 
// 业 务 处 理 
}) ) 


通过 如 上 代码 ， | 
理 即 可 。 不 管 是 数据 异 构 还 是 缓存 更 新 ， 因 为 数据 吏 在 这 里 ， 怎 么 处 理 
号 是 业务 逻辑 的 事情 了 。 


京东 内 部 有 一 个 类 似 的 组 件 BinLake， 和 截止 本 书 出 版 前 暂 未 开源 。Canal 开 
源 版 本 只 提供 了 MySQL 日 志 解 析 ， 如 果 想 要 Oracle 日 志 解 析 ， 则 可 以 使 
用 LinkedIn 的 Databus ° 


第 4 部 分 案例 


+ 构建 需求 响应 式 亿 级 商品 详情 页 

京东 商品 详情 页 服务 闭环 实践 

- 使 用 OpenResty 开发 高 性 能 Web 应 用 
-应 用 数据 静态 化 架构 高 性 能 单 页 Web 应 用 
- 使 用 OpenResty JT A Web 服务 

- 使 用 OpenResty 开发 商品 详情 页 


16 ”构建 需求 啊 应 式 亿 级 商品 详情 页 
16.1 商品 详情 页 是 什么 


商品 详情 页 是 展示 商品 详细 信息 的 一 个 页 面 ， 其 承载 着 网 站 的 大 部 分 流 
量 和 订单 的 入 口 。 矢 东 商 城 目 前 有 通用 版 、 全 球 购 、 内 购 、 易 车 、 惠 买 
车 、 服 狼 、 拼 购 、 今 日 抄底 等 许多 套 模板 。 各 套 模 板 的 元 数据 是 一 样 
的 ， 只 是 展示 方式 不 一 样 。 目 前 商品 详情 页 的 个 性 化 需求 非常 多 ， 数 据 
来 源 也 非常 多 ， 而 且 许多 基础 服务 做 不 了 的 都 放 我 们 系统 这 里 ， 因 此 ， 
我 们 需要 一 种 架构 能 快速 啊 应 和 优雅 地 解决 这 些 需 求 。 我 们 重新 设计 了 
商品 详情 页 的 架构 ， 主 要 包括 三 部 分 ， 商 品 详情 页 系统 、 商 品 详情 页 统 
一 服务 系统 和 商品 详情 页 动态 服务 系统 。 商 品 详情 页 系统 负责 静 的 部 
分 ， 而 统一 服务 系统 负责 动 的 部 分 ， 动 态 服务 系统 负责 给 内 网 其 他 系统 
提供 一 些 数据 服务 。 


泉 东 商城 目前 有 通用 版 、 全 球 购 、 内 购 、 易 车 、 囊 飞车 、 服 狼 、 拼 购 、 
今日 抄底 等 许多 套 模 板 。 通 用 版 如 下 图 所 示 。 
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16.2 ”商品 详情 页 前 端 结构 


商品 详情 页 前 端 结构 可 以 分 为 如 下 几 个 维度 : 商品 维度 (标题 、 图 片 、 
属性 等 ) 、 主 商品 维度 (商品 介绍 、 规 格 参数 ) 、 分 类 维度 、 商 家 维 
度 、 店 铺 维度 等 。 另 外 ， 还 有 一 些 实时 性 要 求 比较 高 的 数据 ， 如 实时 价 
格 、 实 时 促销 、 广 告 词 、 配 送 至 、 预 售 等 ， 它 们 是 通过 异步 加 载 的 。 
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系 东 商城 还 有 一 些 特殊 维度 数据 ， 比 如 套装 、 手 机 合约 机 等 数据 ， 这 些 
数据 是 主 商 品 数据 外 挂 的 。 


16.3 ”我 们 的 性 能 数据 


在 “6.18” 当 天 ， 束 东 商 城 的 PV 达 到 数 亿 次 ， 当 天 服务 如 端的 啊 应 时 间 人 小 
p c SPINE X HUREZR A) a 8 1000 CO EE SIUS HE Ja BY 58 99 1C 
N E [H o 


平常 性 能 曲线 图 


方法 性 能 曲线 图 
Key. nginx.basic.info 


16.4 a 单 品 页 流量 特点 


um 量 的 特点 是 离散 数据 、 热 点 少 ， 可 以 使 用 各 种 爬虫 、 比 价 软件 
xs 


16.5 单 品 页 技术 架构 发 展 


单 品 页 技术 架构 的 发 展 过程 如 下 图 所 示 。 


全 面 接 入 弹性 云 


16.5.1 ”架构 1.0 
IIS+C#+SQL Server 是 最 原始 的 架构 ， 其 直接 调用 商 UU: 


te, TETLTVRERNJI T — memcached H REFRE 〈 见 下 。 这 种 方式 经 
常 受到 依赖 的 服务 不 稳定 而 导致 的 性 能 抖动 。 


16.5.2 ”架构 2.0 


如 下 图 所 示 的 架构 方案 使 用 了 静态 化 技术 ， 按 照 商品 维度 生成 静态 化 
HTML 。 该 方案 的 主要 思路 介绍 如 下 。 


` 通过 MQ 得 到 变更 通知 。 

-通过 Java Worker 调 用 多 个 依赖 系统 生成 详情 页 HTML 。 
- 通过 rsync 同 步 到 其 他 机 器 。 

` 通过 Nginx 直 接 输 出 静态 页 。 

FATE ot i BH o 


ea 


全 量 静 态 化 Nginx 全 量 静态 化 Nginx 


商品 详情 页 HTML 商品 详情 页 HTML 


rsync 同 步 


商品 相关 系统 


其 他 依赖 系统 


该 方案 的 主要 缺点 介绍 如 下 。 
-假设 只 有 分 类 、 面 包 导 变更 了 ， 那 么 所 有 相关 的 商品 都 要 重 刷 。 
随 着 商品 数量 的 增加 ，rsync 会 成 为 瓶 领 。 


无 法 迅速 啊 应 一 些 页 面 需求 变更 ， 大 部 分 都 是 通过 JavaScript 动 态 更 改 页 
面 元 素 。 


随 着 商品 数量 的 增加 ， 这 种 架构 方案 的 存储 容量 遇 到 瓶 贷 ， 而 且 按 照 商 
品 维度 生成 整个 页 面 ， 会 存在 例如 分 类 维度 变更 束 要 刷新 一 过 这 个 分 类 
下 所 有 信息 的 问题 ， 因 此 ， 我 们 又 改造 了 此 架构 方案 ， 按 照 尾 号 路 由 到 
多 台 机 器 ( 见 下 图 ) 。 


接 六 层 Nginx 


HTML 片 段 H HTMIL 片 段 HTMLHER 


Java Worker Java Worker Java Worker Java Worker Java Worker 


此 方案 的 主要 思路 介绍 如 下 。 


` 容量 问题 通过 按照 商品 尾 号 做 路 由 分 散 到 多 台 机 器 ， 按 照 目 营 商品 单独 
一 人 台 ， 第 三 方 商品 按照 尾 号 分 散 到 10 台 。 


按 维 度 生 成 HTML 片 段 (框架 、 商 品 介绍 、 规 格 参数 、 面 包 悄 、 相 关 分 
类 、 店 铺 信息 ) ， 而 不 是 生成 一 个 大 HTML 。 


. 通过 Nginx SSI 合 并 片段 输出 。 

` 接 入 层 人 负责 负载 均衡 。 

ee RUNE Me n doe 
cy o 


该 方案 的 主要 缺点 介绍 如 下 。 

- 酚 片 文件 太 多 ， 导 致 如 无 法 rsync。 

HDD 做 SSI 合 并 时 ， 高 并 发 性 能 差 ， 此 时 我 们 还 没有 尝试 使 用 SSD 。 
模板 如 果 要 变更 ， 则 数 亿 件 商品 需要 数 天 才能 刷新 完 。 


IPARES, RIAM- Sm, RAAE 
出 。 动 态 渔 染 系统 在 流量 高 峰 时 会 导致 依赖 系统 压力 大 ， 抗 不 住 。 


` 还 是 无 法 迅速 啊 应 一 些 业务 需求 。 

我 们 的 痛 点 包括 以 下 两 点 。 

:之 前 染 构 的 问题 存在 容量 问题 ， 很 快 束 会 出 现 无 法 全 量 静 仿 化 ， 还 是 逢 
要 动态 泻 染 ; 不 过 ， 对 于 全 量 静 态 化 ， 可 以 通过 分 布 式 文件 系统 解决 该 
问题 ， 这 里 介绍 的 方案 没有 演 试 。 


最 主要 的 问题 是 随 着 业务 的 发 展 ， 无 法 满足 迅速 变化 的 需求 ， 以 及 一 些 


变态 的 需求 。 
16.5.3 ”架构 3.0 

现在 我 们 要 解决 以 下 问题 。 

- 能 迅速 响应 迅速 变化 的 需求 和 各 种 变态 的 需求 。 
.支持 各 种 垂直 化 页 面 改版 。 

.页面 模 块 化 。 

- AB 测 试 。 

.高 性 能 、 水 平 扩容 。 

.多 机 房 多 活 、 异 地 多 活 。 


如 下 图 所 示 的 架构 方案 的 主要 思路 介绍 如 下 。 


商品 介绍 等 商品 介绍 
MQ 数据 异 构 MQ 基本 信息 
Worker JIMDB 集 群 
数据 异 构 
JIMD8 集 群 


` 数据 变更 还 是 通过 MQ 通知 。 


数据 异 构 Worker 得 到 通知 ， 然 后 按照 一 些 维度 进行 数据 存储 ， 存 储 到 数 
据 异 构 JIMDB 和 集群 (JIMDB: Redis+ 持 久 化 引擎 ) 中 ， 存 储 的 数据 都 是 未 
加 工 的 原子 化 数据 ， 如 商品 基本 信息 、 商 品 扩展 属性 、 商 品 其 他 的 一 些 
相关 信息 、 商 品 规格 参数 、 分 类 、 商 家 信息 等 。 


` 数据 异 构 Worker 存 储 成 功 后 ， 会 发 送 一 个 MQ 给 数据 同步 Worker， 数 据 
同步 Worker 也 可 以 叫 作 数据 聚合 Worker， 其 按照 相应 的 维度 聚合 数据 并 
存储 到 相应 的 JIMDB 人 集群。 其 中 三 个 维度 包括 : 基本 信息 (基本 信息 + 扩 
展 必 性 等 的 一 个 聚合 ) 、 商 品 介 绍 《PC 版 、 移 动 版 ) 、 其 他 信息 (分 
类 、 商 家 等 维度 ， 其 数据 量 小 ， 直 接 使 用 Redis 存 储 ) ° 


- 此 架构 方案 前 端 会 展示 商品 详情 页 和 商品 介绍 ， 使 用 Nginx+Lua 技 术 获 
取 数 据 并 渲染 模板 输出 。 


男 外 ， 我 们 的 架构 目标 不 仅 仪 是 为 商品 详情 页 提供 数据 ， 只 要 十 Key- 
Value 获取 数据 ， 而 非 关 系 方式 的 数据 ， 我 们 都 可 以 提供 服务 ， 并 且 将 其 
称 之 为 动态 服务 系统 。 


其 他 信息 
Redis 


商品 介绍 等 
JIMDB 集 群 


基本 信息 
JIMDB 集 群 


依赖 服务 


商品 详情 页 
后 端 动态 服务 


数据 异 构 
JIMDB##F 


该 动态 服务 分 为 前 端 和 后 端 ， 即 公 网 还 是 内 网 ， 如 目前 该 动态 服务 为 列 
* 商品 对 比 、 微 信 单 品 页 、 总 代 等 提供 相应 的 数据 来 满足 和 文 持 其 
26 


16.6 FERRIER] 
16.6.1 ”数据 闭环 


商品 基本 信息 * 》 商 品 维度 等 消息 一 一 
规格 参数 —* 品牌 服务 一 一 一 一 
Lr a 4 * 品牌 
热力 图 * ^ 分 类 信息 一 一 一 
[商品 介绍 > 其 他 维度 信息 一 


依赖 系统 MQ 


商品 基本 信息 商品 介绍 其 他 信息 


v + v 


数据 同步 MQ 


数据 闭环 即 数据 的 目 我 管理 ， 或 者 说 是 数据 都 在 目 己 系 统 里 维护 ， 不 依 
赖 于 任何 其 他 系统 ， 即 去 依赖 化 这 样 的 好 处 是 别人 拌 动 不 会 影响 到 我 。 
数据 闭环 包括 下 面 儿 个 方面 。 


` 数据 异 构 ， 这 是 数据 闭环 的 第 一 步 ， 即 将 各 个 依赖 系统 的 数据 拿 过 来 ， 
按照 自己 的 要 求 存储 起 来 。 


-数据 原子 化 ， 数 据 异 构 的 数据 是 原子 化 数据 ， 这 样 未 来 我 们 可 以 对 这 些 
数据 再 加 工 再 处 理 ， 从 而 啊 应 变化 的 需求 。 


` 数据 聚合 ， 将 多 个 原子 数据 聚合 为 一 个 大 JSON 数 据 ， 这 样 前 端 展示 只 
需要 一 次 获取 ， 当 然 要 考虑 系统 架构 ， 比 如 我 们 使 用 的 Redis 改 造 ，Redis 
又 是 单线 程 系统 ， 我 们 需要 部 嗜 更 多 的 Redis 来 文 持 更 高 的 并 发 ， 另 外 存 
储 的 值 要 尽 可 能 小 。 


- 数据 存储 ， 我 们 使 用 JIMDB 、Redis 加 持久 化 存储 引擎 可 以 存储 超过 内 
TEN 倍 的 数据 量 。 我 们 目前 的 一 些 系统 使 用 的 是 Redis+LMDB 引 擎 的 存 
储 ， 是 配合 SSD 进 行 存储 。 男 外 ， 我 们 使 用 Hash Tag 机 制 把 相关 的 数据 哈 
希 到 同一 个 分 片 ， 这 样 使 用 mget 时 不 需要 跨 分 片 合并 。 


我 们 目前 的 异 构 数 据 是 键 值 结构 ， 用 于 按照 商品 维度 查询 ， 还 有 一 套 异 
构 数 据 是 关系 结构 的 ， 用 于 关系 查询 。 


16.6.2 ”数据 维度 化 


数据 应 该 按照 维度 和 作用 进行 维度 化 ， 这 样 可 以 分 离 存 储 ， 进 行 更 有 效 
地 存储 和 使 用 。 示 例 数 据 的 维度 比较 简单 ， 如 下 。 


品 基 本 信息 ， 包 括 标 题 、 扩 展 属性 、 特 殊 必 性、 图 片 、 颜 色 扩 码 、 规 


ERG. 


-商品 介绍 信息 ， 包 括 商品 维度 商家 模板 、 商 品 介绍 等 。 


等 
- 非 商 品 维度 的 其 他 信息 ， 包 括 分 类 信息 、 商 家 信息 、 后 铺 信息 、 店 铺 


:商品 维度 其 他 信息 〈 弄 步 加 载 ) ， 包 括 价格 、 促 销 、 配 送 至 、 广 告 词 、 
推荐 配件 、 最 佳 组 合 等 。 


fe 
Ol 


16.6.3 FORA 
商品 介绍 等 商品 介绍 
JIMDB 集 群 Nignx+Lua 


基本 信息 
JIMDB 集 群 


数据 异 构 其 他 信息 
JIMD8 集 群 Redis 


将 系统 拆 分 为 多 个 子 系统 虽然 增加 了 复杂 性 ， 但 是 可 以 得 到 更 多 的 好 
处 ， 比 如 数据 异 构 系统 存储 的 数据 是 原子 化 数据 ， 这 样 可 以 按照 一 些 维 
度 对 外 提供 服务 ;数据 同步 系统 存储 的 是 聚合 数据 ， 可 以 为 前 端 展示 提 
供 高 性 能 的 读 取 ; 前 端 展示 系统 分 离 为 商品 详情 页 和 商品 介绍 ， 可 以 城 
° 目前 商品 介绍 系统 还 提供 其 他 一 些 服 务 ， 比 如 全 站 异步 页 
A FS 


16.6.4 “Worker 无 状态 化 + 任务 化 


任 任 失 
务 务 败 
等 排 任 
待 重 务 
队 队 队 
列 列 列 


对 数据 异 构 和 数据 同步 Worker 进 行 无 状态 化 设计 ， 这 样 可 以 水 平 扩展 。 


:应 用 虽然 是 无 状态 化 的 ， 但 是 配置 文件 还 是 有 状态 的 ， 每 个 机 房 一 套 配 
置 ， 这 样 每 个 机 房 只 读 取 当前 机 房 数 据 。 


任务 多 队列 化 ， 包 括 任务 等 竺 队列 、 包 括 任务 排 重 队列 、 本 地 任务 队 
列 、 失 败 任务 队列 。 


:队列 优先 级 化 ， 分 为 普通 队列 、 刷 数据 队列 、 高 优先 级 队列 。 比 如 ， 一 
些 秒杀 商品 会 用 到 高 优先 级 队列 ， 保 证 任务 快速 执行 。 


` 任务 副本 队列 ， 当 上 线 后 业务 出 现 问 题 时 ， 修 正 逻 辑 可 以 回放 ， 从 而 修 
复数 据 。 可 以 按照 诸如 固定 大 小 队列 或 者 小 时 队列 来 进行 设计 。 


-在 设计 消 思 时， 按照 维度 更 新 ， 比 如 商品 信息 变更 和 商品 上 下 架 分 离 ， 
减少 每 次 变更 接口 的 调用 量 ， 通 过 聚合 Worker 去 做 聚合 。 


16.6.5 “异步 化 + 并 发 化 


我 们 系统 大 量 使 用 异步 化 ， 通 过 异步 化 机 制 提升 并 发 能 力 。 首 先 ， 我 们 
使 用 了 消息 异步 化 进行 系统 解 耦 合 ， 通 过 请 息 通 知 变更 ， 然 后 再 调用 相 
应 接口 获取 相关 数据 。 之 前 老 系统 使 用 同步 推送 机 制 ， 这 种 方式 下 系统 
征 紧 耦合 的 ， 出 问题 时 需要 联系 各 个 负责 人 重 痢 推送 ， 还 要 考虑 失败 重 
斌 机制。 缓存 数据 更 新 异步 化 ， 同 步调 用 服务 ， 但 异步 更 新 缓存 。 让 可 


并 行 任务 并 发 化 ， 虽 然 商品 数据 系统 来 源 有 多 处 ， 但 是 可 以 并 发 调用 聚 
合 ， 这 样本 来 单行 需要 1s 的 任务 ， 使 用 这 种 方式 后 只 需要 不 到 300ms。 异 
步 请 求 做 合并 ， 然 后 一 次 请 求 调用 束 能 拿 到 所 有 数据 。 前 端 服务 异步 化 / 
聚合 ， 实 时 价格 、 实 时 库存 异步 化 ， 使 用 如 线程 或 协 程 机 制 将 多 个 可 并 
发 的 服务 紊 合 。 有 异步 化 还 一 个 好 处 就 是 可 以 对 异步 请 求 做 合并 ， 原 来 N 
次 调用 可 以 合并 为 一 次 ， 还 可 以 做 请 求 的 排 重 。 


16.6.6 “多 级 缓存 化 


. 浏览 器 缓存 : 当 页 面 之 间 来 回 跳 转 时 走 local cache， 或 者 打开 页 面 时 拿 
Æ Last-Modified Æ CDN$ UE MTH, APE J DA RD R E fe Ha RI dia 
量 。 


. CDNF: 用 户 去 离 自 己 最 近 的 CDN 节 点 拿 数据 ， 而 不 是 都 回 源 到 北 
京 机 房 获 取 数 据 ， 这 样 可 以 提升 访问 性 能 。 


- 服务 器 端 应 用 本 地 缓存 : 我们 使 用 Nginx+Lua 架 构 ， 使 用 HttpLuaModule 
ins 的 shared dict 做 本 地 缓存 (reload PER) 或 内 存 级 Proxy Cache, M 
而 减少 带宽 。 


另外 ， 我 们 还 使 用 一 致 性 哈 希 《如 商品 编号 /分 类 ) 做 负载 均衡 ， 内 部 对 
URL 重 写 提升 命中 率 。 


我 们 对 mget 做 了 优化 ， 如 对 于 商品 其 他 维度 数据 ， 分 类 、 面 包 悄 、 商 家 
等 差不多 8 个 维度 数据 ， 每 次 mget 获 取 性 能 差 而 且 数 据 量 很 大 ， 基 本 在 
30KB 以 上 。 而 这 些 数据 缓存 半 小 时 也 是 没有 问题 的 ， 因 此 我 们 设计 为 先 
读 ]ocal cache， 然 后 把 不 命中 的 再 回 源 到 remote cache 获 取 ， 这 个 优化 减少 
了 一 半 以 上 的 remote cache 流 量 。 


服务 需 端 分 布 式 缓存 ， 我 们 使 用 内 存 +SSD+JIMDB 持 久 化 存储 。 


16.6.7 “动态 化 


` 数据 获取 动态 化 : 商品 详情 页 按 维度 获取 数据 ， 如 商品 基本 数据 、 其 他 
数据 〈 分 类 、 商 家 信息 等 ) 。 而 且 可 以 根据 数据 属性 按 需 做 逻辑 ， 比 如 
虚拟 商品 需要 上 自己 定制 详情 页 ， 那 么 我 们 束 可 以 跳 转 ， 比 如 ， 全 球 购 的 
需要 走 jd.hk 域 名 ， 那 么 也 是 没有 问题 的 。 


.模板 泻 染 实时 化 ， 支持 随时 变更 模板 需求 。 


` 重启 应 用 秒 级 化 使 用 Nginx+Lua 架 构 ， 重 启 速度 快 ， 且 不 会 丢 共享 字 
典 缓 存 数 据 。 


` 需求 上 线 快速 化 : 因为 我 们 使 用 了 Nginx+Lua 架 构 ， 因 而 可 以 快速 上 线 
和 重启 应 用 ， 不 会 产生 抖动 。 另 外 ，Lua 本 身 是 一 种 脚本 语言 ， 我 们 也 在 
答 试 把 代码 版 本 化 存储 ， 直 接 内 部 碟 动 Lua 代 码 更 新 上 线 ， 而 不 需要 重启 
Nginx ? 


16.6.8 ”弹性 化 


我 们 所 有 业务 都 使 用 Docker 容 侨 ， 但 古 数据 库存 储 还 是 物理 机 。 我 们 会 
制作 一 些 基础 镜像 ， 把 需要 的 软件 打包 成 镜像 ， 这 样 束 不 用 每 次 去 运 维 
那 安 逆 部 署 软件 了 。 未 来 可 以 文 持 和 目 动 扩容 ， 比 如 ， 按 照 CPU 或 带宽 目 
动 扩容 机 器 ， 目 前 系 东 的 一 些 业务 文 持 一 分 钟 目 动 扩容 。 


16.6.9 ”降级 开关 


推送 服务 器 推送 降级 开关 ， 使 开关 集中 化 维护 ， 然 后 通过 推送 机 制 推送 
到 各 个 服务 器 。 


可 降级 的 多 级 读 服务 为 前 端 数据 集群 ~ 数据 异 构 集群 ~ 动态 服务 (调用 
依赖 系统 ) 。 这 样 可 以 保证 服务 质量 ,假设 前 端 数 据 集群 的 一 个 磁盘 坏 
了 ， 还 可 以 回 源 到 数据 异 构 集群 获取 数据 。 


将 开关 前 置 化 ， 如 Nginx--AITomcat， 在 Nginx 上 做 开关 请 求 就 到 不 了 后 
端 ， 减 少 后 端 压力 。 


将 可 降级 的 业务 线程 池 隅 离 ， 从 Servlet 3 开始 支持 异步 模型 ，Tomcat7 和 
Jetty8 文 持 Servlet 3， 而 Jetty6 中 的 Continuations 也 是 异步 模型 。 我 们 可 以 
把 请 求 处 理 过 程 进行 分 解 ， 通 过 事件 机 制 进行 更 灵活 的 请 求 处 理 流程 控 
制 。 通 过 这 种 将 请 求 划 分 为 事件 的 方式 ， 我 们 可 以 进行 更 多 控制 。 比 
如 ， 我 们 可 以 为 不 同 的 业务 再 建立 不 同 的 线程 池 进 行 控 制 ， 即 我 们 只 依 
赖 Tomcat 线 程 池 进 行 请 求解 析 ， 对 于 请 求 的 处 理 我 们 交 给 目 己 的 线程 池 
去 完成 。 这 样 Tomcat 线 程 池 束 不 是 我 们 的 瓶颈 ， 不 会 再 出 现 现 在 无 法 优 
化 的 状况 。 通 过 使 用 这 种 异步 化 事件 模型 ， 我 们 可 以 提高 整体 的 吞吐 
量 ， 不 让 慢 速 的 A 业 务 处 理 影 响 到 其 他 业务 处 理 。 慢 的 还 是 慢 ， 但 是 不 影 
啊 其 他 业务 。 我 们 通过 这 种 机 制 还 可 以 把 Tomcat 线 程 池 的 监控 拿 出 来 ， 
出 问题 时 可 以 直接 清空 业务 线程 池 ， 男 外 ， 还 可 以 目 定 义 任务 队列 来 支 
持 一 些 特殊 的 业务 ， 如 下 图 所 示 。 


Tomcat 线 程 池 


请 求 队列 


A 业务 线程 池 E B 业 务 线程 池 


产生 响应 产生 响应 站 产生 响应 
16.6.10 £95 Zi& 


应 用 无 状态 ， 通 过 在 配置 文件 中 配置 各 自 机 房 的 数据 集群 来 完成 数据 读 
取 ， 如 下 页 图 所 示 。 
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商品 介绍 Nginx 


商品 介绍 等 IMDB 群 


商品 介绍 等 JIMDB 群 


机 房 A 机 房 B 


数据 集群 采用 一 主 三 从 的 结构 ， 防 止 当 一 个 机 房 不 能 用 时 ， 另 一 个 机 房 
压力 太 大 而 产生 抖动 ， 如 下 图 所 示 。 


同城 机 房 一 主 三 从 ; 从 提供 服务 


机 房 A 机 房 B 


商品 介绍 等 基本 信息 商品 介绍 等 基本 信息 
JIMDB 集 群 JIMDB 集 群 JIMDB 集 群 JIMDB 集 群 


商品 介绍 等 基本 信息 商品 介绍 等 基本 信息 
JIMDB 集 群 JIMDB 集 群 JIMDB 集 群 JIMDB 集 群 


16.6.11 ”两 种 压 测 方案 


第 一 种 是 线 下 压 测 ，Apache ab ^ Apache Jmeter 这 种 方式 是 固定 URL 压 
测 ， 一 般 通 过 访问 日 志 收 集 一 些 URL 进 行 压 测 ， 可 以 简单 压 测 单机 峰值 


吞吐 量 ， 但 是 ， 不 能 作为 最 终 的 压 测 结 有 果 ， 因 为 这 种 压 测 会 存在 热点 问 


第 二 种 是 线 上 压 测 ， 可 以 使 用 Tcpcopy 直 接 把 线 上 流量 导入 到 压 测 服务 
人 妖 ， 这 种 方式 可 以 压 测 出 机 器 的 性 能 ， 而 且 可 以 把 流量 放大 ， 也 可 以 使 
用 Nginx+Lua 协 程 机 制 把 流量 分 发 到 多 台 压 测 服务 器 ， 或 者 直接 在 页 面 埋 
点 ， 让 用 户 压 测 ， 此 种 压 测 方式 可 以 不 给 用 户 返 回 内 容 。 


16.7 ” 遇 到 的 一 些 坑 和 问题 


16.7.1 SSD 性 能 差 


使 用 SSD 做 KV 存储 时 发 现 人 磁盘 IO 非 常 低 。 配 置 成 RAID 10 的 性 能 只 有 
3~6MB/s。 配 置 成 RAID 0 的 性 能 有 ~130MB/s， 系 统 中 没有 发 现 CPU、 
MEM、 中 上 断 等 瓶颈 。 一 台 服 务 器 从 RAID 1 改 成 RAID 0 后 ， 性 能 只 有 
~60MB/。 这 说 明 我 们 用 的 SSD 熏 性 能 不 稳定 。 


根据 以 上 现象 ， 初 步 怀 疑 两 个 方面 : SSD 盘 ， 线 上 系统 用 的 三 星 840Pro 是 
消费 级 硬盘 ; RAID 卡 设置 ，Write back 和 Write through 策 略 。 后 来 测试 验 
证 ，RAID 有 影响 ， 但 不 是 关键 。 关 于 RAID 卡 类 型 ， 线 上 系统 用 的 是 LSI 
2008， 比 较 陈 旧 。 


m $3610 RAIDO 
m 53610 RAID1 

m 840Pro RAIDO 
m 840Pro RAID1 


4KB KB 16KB  32KB 1024KB 
数据 块 大 小 


本 实验 使 用 dd 顺序 写 操作 进行 简单 测试 ， 严 格 测试 需要 用 FIO 等 工具 。 
16.7.2 ” 键 值 存储 选 型 压 测 


我 们 在 存储 选 型 时 尝试 过 LevelDB、RocksDB、BeansDB、LMDB、Riak 
等 ， 最 终 根据 我 们 的 需求 选择 了 LMDB 。 


uas: 两 台 


. 配置 : 32 核 CPU、32GB 内 存 、SSD ( (512GB) 三 星 840Pro > 
(600GB) Intel 3500 /Intel S3610 ] 


BB: 1.7 亿 数据 (超过 800GB 的 数据 ) 、 大 小 5~30KB 左 右 
.KV 存 储 引擎 ,LevelDB、RocksDB、LMDB， 每 台 启 动 两 个 实例 
- 压 测 工具 : tcpcopy 直 接线 上 导 流 

- 压 测 用 例 :， 随 机 写 + 随 机 读 


LevelDB 压 测 时 ， 随 机 读 + 随 机 写 会 产生 拌 动 (我 们 的 数据 出 自 自己 的 监 
控 平台 ， 分 钟 级 采样 ) ,参见 下 图 。 


LevelDB 读 : 50w/ 分 钟 ， 写 : 5w/ 分 钟 


4000 ms 


> TP50 = TP90 TP99 w TP999 = MAX AVG > MN 


RocksDB 是 改造 目 LevelDB， 对 SSD 做 了 优化 ， 我 们 压 测 时 采用 单独 写 或 


读 ， 性 能 非常 好 ， 但 是 读 写 混 合 时 束 会 因为 归并 产生 抖动 ， 参 见 下 页 第 


RocksDB 读 : 80w/ 分 钟 ， 写 : 2.3w/ 分 钟 
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> TPSO e TPSO 4P TROD wr TP999 = MAX @ AVE © MN 


LMDB3 引 警 没 有 大 的 拌 动 ， 基 本 满足 我 们 的 需求 ， 参 见 下 图 。 


LMDB ix : 80w/ 分 钟 , 


目前 线 上 我 们 的 服务 器 使 用 的 就 是 LMDB 。 
16.7.3 “数据 量 大 时 JIMDB 同 步 不 动 


JIMDB 数 据 同步 时 要 Dump 数 据 ，SSD 极 容量 用 了 50% 以 上 ，Dump 到 同一 
ER ELA BN KE ° RARU F ° 


. 一 台 物 理 机 挂 两 块 SSD (512GB) , FAFERAID 0。 启 动 8 个 JIMDB 实 
例 。 这 样 每 实例 差不多 是 125GB 左 右 。 目 前 是 挂 4 块 RAID 0。 新 机 房 计 划 
挂 8 块 RAID 10。 

- 目前 是 千 兆 网 卡 同步 ， 同 步 峰 值 在 100MB/s 左 右 。 

.Dump 和 sync 数 据 时 是 顺序 读 写 ， 因 此 挂 一 块 SAS 盘 专门 来 同步 数据 。 

- 使 用 文件 锁 保 证 一 台 物 理 机 多 个 实例 同时 只 有 一 个 Dump。 


后 续 计 划 改 造 为 直接 内 存 转发 ， 而 不 做 Dump 。 


16.7.4 WEM 


之 前 存储 架构 是 一 主 二 从 〈 主 机房 一 主 一 从 ， 备 机 房 一 从 ) ， 切 换 到 备 
机 房 时 ， 只 有 一 台 主 服务 器 ， 读 写 压力 大 时 有 拌 动 ， 因 此 我 们 改造 为 之 
前 架构 图 中 的 一 主 三 从 。 


16.75 ”分 片 配置 


之 前 的 架构 是 分 片 逻 辑 分 散 到 多 个 子 系统 的 配置 文件 中 ， 切 换 时 需要 操 
作 很 多 系统 ， 解 决 方案 如 下 。 


| 入 Twemproxy 中 间 件 ， 我 们 使 用 本 地 部 署 的 Twemproxy 来 维护 分 片 逻 
HH [9] 


o NUMINIS 应 用 ， 重 局 之 前 暂停 MQ 消费 保证 数 


- 用 unix domain socket 减 少 连 接 数 ， 以 及 问 口 占用 不 释放 导致 局 动 不 了 服 


务 的 问题 。 
16.7.6 ”模板 元 数据 存储 HTML 


起 初 不 确定 Lua 做 逻辑 和 渲染 模板 性 能 如 何 ， 就 尽量 减少 for、if/else 之 类 
的 逻辑 。 通 过 Java worker 组 装 HTML 片段 存储 到 JIMDB，HTML 片段 会 存 
储 诸 多 问题 ， 假 设 未 来 变 了 也 是 需要 全 量 刷 出 的 ， 因 此 存储 的 内 容 最 好 
是 元 数据 。 通 过 线 上 不 断 压 测 ， 最 终 JIMDB 只 存储 元 数据 ，Lua 做 逻辑 和 
渲染 。 逻 辑 代码 在 3000 行 以 上 。 模 板 代 码 在 1500 行 以 上 ， 其 中 有 大 量 
for、ifelse 语 句 ， 目 前 浑 染 性 能 可 以 接受 o 


线 上 真实 流量 ， 整 体 性 能 从 TP99 为 53ms 降 到 TP99 为 32ms， 人 参见 下 图 。 


2015-03-27 00:00:00 
f 2015-03-29 00:00:00 
P50: 7 ms poi» 
TP90. 18 ms rins im. 
TP99: 55 ms napis n "s 
TP999- 102 ms E eal 
MAX: 1,000 ms P999 ms 
" MAX. 1,000 ms 
AVG: 10 ms Á 
AVG : 10 ms 


MN: lms 


~N: 1 ms 


06/16 00:00 06/1800:00 06/20 00:00 06/22 00:00 06/24 00:00 06/26 00:00 06/28 00:00 06/30 00:00 € 


œ TPSO -*- TP90 <& TP99 -4- TP999 - MAX -œ AVG -> MIN 


16.7.7 “库存 接口 访问 量 600w/ 分 钟 


商品 详情 页 库存 接口 在 2014 年 曾 被 恶意 刷 流 量 ， 每 分 钟 超 过 600w 访 问 
量 ，Tomcat 机 器 只 能 定时 重启 。 因 为 是 详情 页 展示 的 数据 缓存 几 秒 钟 是 
可 以 接受 的 ， 因 此 开局 Nginx Proxy Cache 来 解决 该 问题 ， 开 启 后 访问 量 
降 到 了 正常 水 平 。 我 们 目前 正在 使 用 Nginx+Lua 架 构 改 造 服务 ， 数 据 过 
滤 、URL 重 写 等 在 Nginx 层 完成 ， 通 过 URL 重 写 和 一 至 性 哈 希 负载 均衡 ， 
我 们 不 再 惧 人 随机 URL， 一 些 服 务 提 升 了 10% 以 上 的 缓存 命中 率 。 


16.7.8 ” 微 信 接口 调用 量 暴 增 


通过 访问 日 志 发 现 某 IP 频 繁 抓 取 。 而 且 按 照 商 品 编号 滔 历 ， 但 是 会 有 一 
些 不 存在 的 编写， 解决 方案 如 下 。 


. 读 取 KV 存储 的 部 分 不 限 流 。 
- 回 源 到 服务 接口 进行 请 求 限 流 ， 保 证 服务 质量 。 
16.7.9 ”开局 Nginx Proxy Cache 性 能 不 升 反 降 


开启 Nginx Proxy Cache 后 ， 性 能 下 降 ， 而 且 过 一 段 内 存 使 用 率 到 达 98%， 
解决 方案 如 下 。 


.内存 占用 率 高 的 问题 是 内 核 问 题 ， 内 核 使 用 LRU 机 制 ， 本 喘 不 是 问题 ， 
不 过 可 以 通过 修改 内 核 参数 来 改善 : 


sysctl -w vm.extra free kbytes-6436787 
sysctl -w vm.vfs cache pressure-10000 


.在 HDD 上 使 用 Proxy Cache 性 能 差 ， 可 以 通过 tmpfs 绥 存 或 Nginx 共 享 字 典 
缓存 元 数据 ， 或 者 使 用 SSD， 我 们 目前 使 用 内 存 文 件 系 统 。 


16.7.10 ”配送 至 读 服 务 因 依 赖 太 多 ， 啊 应 时 间 偏 慢 
配送 至 服务 每 天 有 数 十 亿 调用 量 ， 响 应 时 间 偏 慢 ， 解 决 方案 如 下 。 


. 串 行 获取 变 并 发 获取 ， 这 样 一 些 服务 可 以 并 发 调用 ， 在 我 们 某 个 系统 
能 提升 一 倍 多 的 性 能 ， 从 原来 TP99 差 不 多 1s 降 到 500ms 以 下 。 

- 预 取 依赖 数据 回 传 ， 这 种 机 制 还 有 一 个 好 处 ， 比 如 我 们 依赖 三 个 下 游 服 
务 ， 而 这 三 个 服务 都 需要 商品 数据 ， 那 么 我 们 可 以 在 当前 服务 中 取 数 
据 ， 然 后 回 传 ， 这 样 可 以 减少 下 游 系统 的 商品 服务 调用 量 。 如 果 没 有 
传 ， 那么 下 游 服 务 再 自己 查 一 下 。 


数据 如 下 表 所 示 。 


如 采 串 行 获 取 ， 则 需要 60ms。 


而 如 果 数 据 C 依 赖 数 据 A 和 数据 B， 数 据 D 谁 也 不 依赖 ， 数 据 E 依 赖 数据 
C， 那 么 我 们 可 以 这 样 来 获取 数据 : 


数 | 数 X 
| 据 | oe | 据 
A B D 


以 这 种 获取 数据 只 需要 30ms， 能 提升 一 倍 的 性 能 。 
假设 数据 E 还 依赖 数据 F (5ms) ， 而 数据 F 是 在 数据 E 服 务 中 获取 的 ， 此 
时 束 可 以 考虑 在 获取 数据 A/B/D 时 ， 预 取 数 据 FE， 那 么 整体 时 间 束 变 为 了 


25ms ° 


通过 这 种 优化 ， 服 务 的 整体 性 能 的 TP99 差 不 多 降低 了 10ms。 


06/28 02:00 


如 下 服务 是 在 抖动 时 的 性 能 ， 老 服务 的 TP99 为 211ms， 痢 服务 的 TP99 为 
118ms， 此 处 我 们 主要 束 是 并 发 调用 + 超时 时 间 限 制 ， 超 时 直接 降级 。 


TP99: 118 ms 
TP999: 573 ms 
MAX: 969 ms 
AVG: 18 ms 
MIN: 1 ms 


16.7.11 网络 拌 动 时 ， 返 回 502 错 误 
Twemproxy 配 置 的 timeout 时 间 太 长 ， 之 前 设置 为 5s， 而 且 没 有 分 别针 对 连 
接 、 读 、 写 设置 超时 。 后 来 我 们 减少 超时 时 间 ， 内 网 设置 在 150ms 以 内 ， 
当 超 时 时 访问 动态 服务 。 


16.7.12 ”机 器 流量 太 大 


2014 年 “ 双 11” 期 间 ， 服 务 器 网 卡 流 量 到 了 400Mbps，CPU 的 使 用 率 在 30% 
左右 。 原 因 是 我 们 所 有 压缩 都 在 接 入 层 完成 ， 因 此 接 入 层 不 再 把 相关 请 
求 头 传 入 到 应 用 ， 随 着 流量 的 增 大 ， 接 入 层 压 力 过 大 ， 因 此 我 们 把 压缩 
下 放 到 各 个 业务 应 用 ， 添 加 了 相应 的 请 求 凑 ，Nginx GZIP 压 缩 级 别 为 2~4 
时 吞吐 量 最 高 。 应 用 服务 器 流量 降 了 5 倍 左 右 。 目 前 正常 情况 CPU 的 使 用 
率 在 4% 以 下 。 


16.8 ”其 他 


在 Nginx 接 入 层 实现 线 上 灰 度 引流 。 在 接 入 层 转 发 请 求 时 只 保留 有 用 请 求 
头 ， 因 而 后 端 Tomcat 不 必 解 析 无 用 的 请 求 头 。 使 用 不 带 Cookie 的 无 状态 域 
名 (如 c.3.cn) 减少 请 求 流量 ， 比 如 jd.com 域 名 下 边 可 能 存在 1KB 的 
Cookie， 但 是 服务 器 端 根本 不 需要 。Nginx Proxy Cache 只 缓存 有 效 数 据 ， 
如 托 底 数据 不 缓存 ， 避 免 缓存 一 些 错误 的 数据 。 使 用 非 阻 塞 锁 应 对 本 地 
绥 存 失效 时 突 发 请 求 到 后 端 应 用 (Iua-resty-lock/proxy. cache lock) 。 使 
用 Twemproxy 等 代理 减少 Redis 连 接 数 。 使 用 unix domain socket £z F DÀ 
少 本 机 TCP 连 接 数 。 设 置 合 理 的 超时 时 间 (连接 、 读 、 写 ) 。 使 用 长 连接 
减少 内 部 服务 的 连接 数 。 去 数据 库 依 赖 《协调 部 门 迁 移 数 据 库 是 很 痛苦 
的 ， 目 前 内 部 使 用 机 房 域名 而 不 是 耻 地 址 ) 。 客 户 端 同 域 连 接 限 制 ， 进 
行 域名 分 区 : c0.3.cn、c1.3.cn， 如 果 未 来 支持 HTTP/2.0 的 话 ， 则 不 再 适 
用 o 


想 要 了 解 京 东 手 机 详情 页 架构 ， 可 扫 二 维 码 参考 《京东 手机 商品 详情 页 
技术 解密 》。 


17 ” 束 东 商品 详情 页 服务 闭环 实践 


京东 商品 详情 页 技术 方案 在 第 16 章 已 经 详细 介绍 了 ， 接 下 来 为 大 家 揭秘 
双 11 抗 下 几 十 亿 流 量 的 商品 详情 页 统一 服务 架构 ， 这 次 双 11 整 个 商品 详 
情 页 没有 出 现 不 服务 的 情况 ， 服 务 非 第 稳定。 统一 服务 提供 了 促销 和 广 
告 词 合并 服务 、 库 存 状 态 /配送 至 服务 、 延 保 服 务 、 试 用 服务 、 推 荐 服 
务 、 图 书 相 关 服 务 、 详 情 页 优惠 券 服 务 、 今 日 抄底 服务 等 服务 支持 。 这 
些 服 务 中 有 我 们 目 己 做 的 服务 实现 ， 还 有 一 些 是 简单 做 一 下 代理 或 者 接 
口 ， 做 合并 输出 到 页 面 ， 我 们 将 这 些 服 务 聚 合 到 一 个 系统 的 目的 是 打造 
服务 闭环 ， 优 化 现 有 服务 ， 并 为 未 来 需求 做 准备 ， 跟 着 自己 的 方 同 走 ， 
而 不 被 别人 打 乱 我 们 的 方向 。 


大 家 在 页 面 中 看 到 的 c.3.cn/c0.3.cn/c1.3.cn/cd.jd.com 请 求 都 是 统一 服务 的 
A 


17. 为 什么 需要 统一 服务 


商品 详情 页 虽然 只 有 一 个 页 面 ， 但 是 依赖 的 服务 众多 ， 我 们 需要 把 控 好 
入 口 ， 统 一 化 管理 。 这 样 的 好 处 是 在 统一 管理 和 监控 下 ， 出 问题 可 以 统 
一 降级 。 可 以 把 一 些 相 关 接 口 合并 输出 ， 减 少 页面 的 异步 加 载 请 求 。 一 
些 前 端 逻 辑 后 移 到 服务 器 端 ， 前 端 只 做 展示 ， 不 进行 逻辑 处 理 。 


有 了 它 ， 所 有 入 口 都 在 我 们 的 服务 中 ， 我 们 可 以 更 好 地 监控 和 思考 我 们 
页 面 的 服务 ， 让 我 们 能 运筹 于 帷 帐 之 中 ， 决 胜 于 千里 之 外 。 在 设计 一 个 
高 度 灵活 的 系统 时 ， 要 想 着 当 出现 问 题 时 怎么 办 : 是 否 可 降级 ? 不 可 降 
级 怎么 处 理 ? 是 否 会 发 送 滚雪球 问题 ? 如 何 快速 啊 应 异常 ? 完成 了 系统 
核心 逻辑 只 能 保证 服务 能 工作 ， 服 务 如 何 更 好 更 有 效 或 者 在 异常 情况 下 
正常 工作 ， 也 古 我 们 要 深入 思考 和 解决 的 问题 。 


17.2 ”整体 架构 


Twemproxy 


1 | Nginx Cache 
Noii 


^. 


*. 


Tomcat Twemproxy 
5 


RLS 


整体 流程 如 下 。 


1. 请 求 首先 进入 Nginx，Nginx 调 用 Lua 进 行 一 些 前 置 逻辑 处 理 ， 如 果 前 置 
mln 那么 直接 返回 ， 然 后 查询 本 地 缓存 ， 如 果 命 中 ， 则 直接 返 


2. 如 有 果 本 地 缓存 未 命中 数据 ， 则 查询 分 布 式 Redis 集 群 ， 如 果 命 中 数据 ， 
则 直接 返回 。 


3. 如 果 分 布 式 Redis 集 群 未 命中 数据 ， 则 调用 Tomcat 进 行 回 源 处 理 。 然 后 
把 结果 异步 写 入 Redis 集 群 ， 并 返回 。 


如 上 是 整个 逻辑 流程 ， 可 以 看 到 我 们 在 Nginx 这 一 层 做 了 很 多 前 置 逻 辑 处 
理 ， 以 此 来 减少 后 端 压 力 ， 男 外 ， 我 们 的 Redis 集 群 分 机 房 部 署 如 下 图 所 


修 ° 


A 机 房 
Nginx+Lua 
从 Redis 集 群 。” «- 
Nginx+Lua 
LVS+HAProxy — 
BILE; 
Nginx+Lua 
从 Redis 集 群 < 
Nginx+Lua 


更 新 缓存 一 了 > 主 Redis 集 群 


Tomcat | | Tomcat | Tomcat «—4 li 


即 数 据 会 写 一 个 主 集群 ， 然 后 通过 主 从 方式 把 数据 复制 到 其 他 机 房 ， 各 
个 机 房 读 目 己 的 集群 。 此 处 没有 在 各 个 机 房 做 一 套 独 立 的 集群 来 保证 机 
房 之 间 没 有 交叉 访问 ， 这 样 做 的 目的 是 保证 数据 一 致 性 。 


在 这 套 新 架构 中 ， 可 以 看 到 Nginx+Lua 已 经 是 应 用 的 一 部 分 ， 我 们 在 实际 
使 用 中 也 是 把 它 作 为 项 目 进行 开发 ， 作 为 应 用 进行 部 署 。 


17.3 一 些 架 构思 路 和 总 结 
我 们 主要 遵循 如 下 几 个 原则 设计 系统 架构 。 


17.3.1 ”两 种 读 服务 架构 模式 

1. 读 取 分 布 式 Redis 数 据 架构 

如 下 图 所 示 可 以 看 到 Nginx 应 用 和 Redis 单 独 部 署 ， 这 种 方式 是 一 般 应 用 的 
部 署 模式 ， 也 是 我 们 统一 服务 的 部 署 模式 ， 此 处 会 存在 跨 机 器 、 跨 交换 
机 或 跨 机 柜 读 取 Redis 缓 存 的 情况 ， 但 是 不 存在 跨 机 房 情况 ， 因 为 是 通过 


主 从 方式 把 数据 复制 到 各 个 机 房 。 如 采 对 性 能 要 求 不 是 非常 苛刻 ， 则 可 
以 考虑 这 种 架构 ， 比 较 容 易 维 护 。 


A 机 房 
Nginx+Lua — E 
从 Redis 集 群 - 4 
| 
Nginx+Lua | 
| 
LV9+HAProxy 

| 
B 机 房 | | 
Nginx+Lua | 
从 Redis 集 群 < F 
Nginx+Lua | 
| 
| 
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2. 读 取 本 地 Redis 数 据 架 构 


如 下 图 所 示 ， 可 以 看 到 Nginx 应 用 和 Redis 集 群 部 署 在 同一 台 机 器 上 ， 这 样 
的 好 处 是 可 以 消除 跨 机 器 、 跨 交换 机 或 跨 机 柜 ， 甚 至 跨 机 房 调用 。 如 果 
本 地 Redis 集 群 不 命中 ， 则 还 是 回 源 到 Tomcat 集 群 进行 取 数 据 。 此 种 方式 
可 能 受 限 于 TCP 连 接 数 ， 可 以 考虑 使 用 unix domain socket 套 接 字 减少 本 机 
TCP 连 接 数 。 如 果 单 机 内 存 成 为 瓶 贷 (比如 单机 内 存 最 大 为 256GB) , 3b 
么 就 需要 路 由 机 制 来 进行 分 片 ， 比 如 ， 按 照 商 品 尾 号 分 片 ，Redis 集 群 一 
般 采 用 树 状 结构 挂 主 从 部 署 。 


LVS+HAProxy 


=] 
从 Redis 集 群 


=} 
从 Redis 集 群 


=} 
从 Redis 集 群 


17.3.2 ”本 地 缓存 


我 们 把 Nginx 作 为 应 用 部 署 ， 因 此 我 们 大 量 使 用 Nginx 共 享 字 典 作为 本 地 
缓存 。 在 Nginx+Lua 架 构 中 ， 使 用 HttpLuaModule 模 块 的 shared dict 做 本 地 
缓存 (reload 不 丢失 ) 或 内 存 级 Proxy Cache， 提 升 缓存 带 来 的 性 能 并 减少 
带宽 消耗 。 另 外 ， 我 们 使 用 一 致 性 哈 希 (如 商品 编号 /分 类 ) 做 负载 均 
衡 ， 内 部 对 URL 重 写 提 升 命中 率 。 


我 们 在 缓存 数据 时 ， 采 用 了 维度 化 存储 缓存 数据 ， 增 量 获 取 失 效 缓存 数 
据 (比如 10 个 数据 ，3 个 没命 中 本 地 缓存 ， 只 需要 取 这 3 个 即 可 ) 。 维 度 
如 商家 信息 、 店 铺 信息 、 商 家 评分 、 店 铺 头 、 品 牌 信 息 、 分 类 信息 等 。 
比如 ， 我 们 本 地 缓存 30min， 调 用 量 会 减少 3 倍 左右 。 


另外 ， 我 们 使 用 一 致 性 哈 希 和 本 地 缓存 可 以 提升 命中 率 ， 如 库存 数据 缓 
存 5s， 平 常 命中 率 : 本 地 缓存 25%， 分 布 式 Redis 28%， 回 源 47%; 一 次 
普通 秒杀 活动 命中 率 : 本 地 缓存 58%、 分 布 式 Redis 15%， 回 源 27%， 而 
某 个 服务 使 用 一 致 哈 希 后 命中 率 提 升 10%; 防止 URL 顺 序 不 同 导致 缓存 命 
中 率 低 ， 或 存在 一 些 如 时 间 这 种 随机 参数 ， 即 页 面 URL 不 管 怎么 变 都 不 
要 让 它 成 为 缓存 不 命中 的 因素 。 


17.3.3 “多 级 缓存 


对 于 读 服务 ， 我 们 在 设计 时 会 使 用 多 级 缓存 来 尽量 减少 后 端 服务 压力 ， 
在 统一 服务 系统 中 ， 我 们 设计 了 4 级 缓存 ， 如 下 图 所 示 。 


| Nginxf AJE a > Tomcat a 
eo p 
b 1> ae) 一 、 ^ n ae) 一 、 


Lè » (redis ) oie => 
b. jc 
3+ serice) 


1. 首 移 在 搂 入 层 会 使 用 Nginx 本 地 缓存 ， 这 种 前 端 缓 存 主 要 目的 是 抗 热 
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2. 如 果 Nginx 本 地 缓存 不 命中 ， 那 么 接着 会 读 取 各 个 机 房 的 分 布 式 从 Redis 
绥 存 集群 ， 该 缓存 主要 是 保存 大 量 离散 数据 ， 抗 大 规模 离散 请 求 ， 比 
如 ， 使 用 一 致 性 哈 希 来 构建 Redis 集 群 ， 即 使 其 中 的 某 台 机 器 出 问题 ， 也 
会 出 现 雪 有 衣 的 情况 。 


3. 如 果 从 Redis 集 群 不 命中 ， 则 Nginx 会 回 源 到 Tomcat。Tomcat 首 先 读 取 本 
HERT, 这 个 主要 用 来 支持 在 一 个 请 求 中 多 次 读 取 一 个 数据 或 者 与 该 
数据 相关 的 数据 。 而 其 他 情况 命中 率 是 非常 低 的 ， 或 者 缓存 一 些 规模 比 
较 小 但 用 得 非常 频繁 的 数据 ， 如 分 类 、 品 牌 数 据 。 堆 缓存 时 间 我 们 设置 
为 Redi 缓 存 时 间 的 一 半 。 


4. 如 果 Java 堆 缓存 不 命中 ， 则 会 读 取 主 Redis 集 群 ， 正 常情 况 下 该 缓存 命中 
率 非常 低 ， 只 有 不 到 59%。 读 取 该 缓存 的 目的 是 防止 前 端 缓存 失效 之 后 有 
大 量 请 求 涌 入 ， 进 而 导致 后 端 服务 压力 太 大 而 雪 衣 。 我 们 默认 开启 了 该 
缓存 ， 虽 然 增 加 了 几 毫 秒 的 啊 应 时 间 ， 但 是 可 以 加 厚 我 们 的 防护 盾 ， 使 
服务 更 稳当 可 靠 。 此 处 可 以 做 一 下 改善 ， 比 如 我 们 设置 一 个 国 值 ， 超 过 
这 个 靖 值 我 们 才 读 取 主 Redis 集 群 ， 比 如 Guava 束 由 RateLimiter API 来 实 
现 。 


17.3.4 ”统一 入 口 /服务 闭环 


在 第 16 章 中 已 经 讲 过 了 数据 异 构 闭 环 的 收益 ， 在 统一 服务 中 我 们 也 遵循 
这 个 设计 原则 ， 此 处 我 们 主要 做 了 两 件 事情 。 


- 数据 异 构 ， 如 我 们 对 判断 库存 状态 依赖 的 套装 、 配 件 关 系 进行 了 腊 构 ， 
未 来 可 以 对 商家 运费 等 数据 进行 异 构 ， 减 少 接口 依赖 。 


` 服务 闭环 ， 所 有 单 品 页 上 用 到 的 核心 接口 都 接 入 统一 服务 。 有些 是 查 库 / 
缓存 然后 做 一 些 业务 忱 得， 有些 征 HTTP 接口 调用 然后 进行 简 TIT 
辑 处 理 。 还 有 一 些 束 是 做 了 简单 的 代理 ， 并 监控 接口 服务 质量 。 


17.4 引入 Nginx 接 入 层 


我 们 在 设计 系统 时 需要 把 一 些 逻 辑 尽 可 能 前 置 ， 以 此 来 减轻 后 端 核心 逻 
辑 的 压力 ， 而 且 可 以 让 服务 升级 /服务 降级 非常 方便 地 进行 切换 ， 在 接 入 
层 我 们 做 了 如 下 事情 。 


17.4.1 ”数据 校 验 /过 滤 逻 辑 前 置 


我 们 的 服务 有 两 种 类 型 的 接口 :一 种 是 与 用 户 无 关 的 接口 ， 男 一 种 则 是 
与 用 户 相关 的 接口 。 因 此 我 们 使 用 了 两 种 类 型 的 域名 c.3.cn/c0.3.cn/c1.3.cn 
和 cd.jd.com。 当 我 们 请 求 cd.jd.com 时 会 融 着 用 户 Cookie 信 息 到 服务 恬 端 。 
在 服务 右上 会 进行 请 求 头 的 处 理 ， 用 户 无 关 的 所 有 数据 通过 参数 传递 ， 
在 接 入 层 会 丢弃 所 有 的 请 求 头 〈 保 留 gzip 相 关 的 头 ) 。 而 用 户 相关 的 数据 
会 从 Cookie 中 解 出 用 户 信息 ， 然 后 通过 参数 传递 到 后 端 。 也 就 是 后 端 应 
用 从 来 就 不 关心 请 求 头 及 Cookie 信 息 ， 所 有 信息 通过 参数 传递 。 


请 求 进 入 接 入 层 后 ， 会 对 参数 进行 校 验 ， 如 采 参 数 校 验 不 合法 ， 则 直接 
拒绝 这 次 请 求 。 我 们 对 每 个 请 求 的 参数 进行 了 最 严格 的 数据 校 验 处 理 ， 
保证 数据 的 有 效 性 。 如 下 图 所 示 ， 我 们 对 关键 参数 进行 了 过 滤 ， 如 末 这 
些 参数 不 合法 ， 那 么 束 直 接 拒绝 请 求 。 


local skuld = getSkuld(args[’ skuId' ]) --sku 

local venderld = getVenderld(srgs[' venderId' ]) 一 -商家 id 
local cat = getCat (args[" cat’ ]) ——4p 3E 

local area = getÁres(srgs[' area’ ]) —-KEt 
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URL 调 度 到 后 端 应 用 ， 此 时 ，URL 上 的 参数 是 国定 的 而 且 是 有 序 的 ， 可 
以 按照 URL 进 行 缓存 。 


17.4.2 ”缓存 前 置 


我 们 把 很 多 缓存 前 置 到 了 接 入 层 来 进行 热点 数据 的 削 峰 ， 而 且 配合 一 致 
性 哈 希 也 许可 以 提升 缓 在 的 命中 率 。 在 缓存 时 ， 我 们 按照 业务 来 设置 组 
存 池 ， 减 少 相互 之 间 的 影响 并 提升 并 发 率 。 我 们 使 用 Lua 读 到 共享 字典 来 
实现 本 地 缓存 。 


17.4.3 ”业务 逻辑 前 置 


我 们 在 接 入 层 直 接 实 现 了 一 些 业 务 逻 辑 ， 原 因 是 如 采 在 高 峰 时 出 问题 ， 
可 以 在 这 一 层 做 一 些 逻 辑 升 级 。 我 们 后 端 是 Java 应 用 ， 当 修复 逻辑 时 需要 
上 线 ， 而 一 次 上 线 可 能 花费 数 十 秒 时 间 局 动 应 用 ， 重 局 应 用 后 Java 应 用 
JIT 的 问题 会 存在 性 能 拌 动 的 问题 ， 可 能 因为 重启 造成 服务 一 直 启 动 不 起 
来 的 问题 。 而 在 Nginx 中 做 这 件 事情 ， 改 完 代 码 推 送 到 服务 器 ， 重 启 只 需 
要 秒 级 ， 而 且 不 存在 抖动 问题 ， 这 些 逻 辑 都 症 在 Lua 中 完成 的 。 


17.4.4 ”降级 开关 前 置 


我 们 将 降级 开关 分 为 这 么 几 种 : 接 入 层 开 关 和 后 端 应 用 开关 、 总 开关 和 
原子 开关 。 我 们 在 接 入 层 设置 开关 的 目的 是 为 了 防止 降级 后 流量 还 无 谓 
地 打 到 后 端 应 用 。 总 开关 是 对 整个 服务 降级 ， 比 如 ， 库 存 服务 默认 有 
货 。 而 原子 开关 是 对 整个 服务 中 的 一 个 小 服务 降级 ， 比 如 库存 服务 中 需 
要 调用 商家 运费 服务 ， 如 有 果 只 是 商家 运费 服务 出 问题 了 ， 则 此 时 可 以 只 
。 另 外， 我 们 还 可 以 根据 服务 重要 程度 来 使 用 超时 目 
DINEZ l| o 


我 们 使 用 init_by_lua_file 初 始 化 开关 数据 ， 共 享 字典 存储 开头 数据， 提供 

APTI 进 行 开关 切换 (switch get(*stock.api.not.call") ~= *1") 。 可 以 实现 秒 

级 切换 开关 、 增 量 式 切 换 开 关 (可 以 按照 机 器 组 开启 ， 而 不 是 所 有 都 开 

OA ad ` 细 粒 度 服务 降级 开关 ， 非 核心 服务 可 以 实现 超时 
BJ pH#AN o 


比如 ， 双 11 期 间 有 些 服务 出 问题 了 ， 我 们 进行 过 大 服务 和 小 服务 的 降级 
操作 ， 这 些 操作 对 用 户 来 说 都 是 无 感知 的 。 


17.4.5 ABM 


对 于 服务 升级 ， 最 重要 的 就 是 做 A/B 测 试 ， 然 后 根据 A/B 测 试 的 结 采 来 看 
征 否 切换 新 服务 。 而 有 了 搂 入 层 非常 容易 进行 这 种 A/B 测 试 。 不 管 是 上 线 


还 是 切换 都 非常 容易 。 可 以 在 Lua 中 根据 请 求 的 信息 调用 不 同 的 服务 ， 或 
者 通过 upstream 分 组 即 可 完成 A/B 测 试 。 


17.4.6” 灰 度 发 布 /流量 切换 


对 于 一 个 灵活 的 系统 来 说 ， 能 随时 进行 灰 度 发 布 和 流量 切换 是 非常 重要 
的 一 件 事情 ， 比 如 ， 验 证 新 服务 器 是 否 稳定 ， 或 者 验证 新 的 架构 是 否 比 
老 架 构 更 优秀 ， 有 了 时 只 有 在 线 上 运行 才能 看 出 是 否 有 问题 。 我 们 在 接 入 
层 可 以 通过 配置 或 者 写 Lua 代 码 来 完成 这 件 事情 ， 灵 活性 非常 好 。 可 以 设 
置 多 个 upstream 分 组 ， 然 后 根据 需要 切换 分 组 即 可 。 


17.4.7 ”监控 服务 质量 


对 于 一 个 系统 来 说 ， 最 重要 的 是 要 有 一 双眼 睛 能 盯 着 系统 ， 以 便 尽 可 能 
早 地 发 现 问 题 ， 我 们 在 接 入 层 会 对 请 求 进行 代理 ， 记 录 status ^ 
request time ^ response. time2£ I5 445 ARH 质量 ， 比 如 ， 根 据 调用 量 、 状 态 
码 是 否 是 200、 响 应 时 间 来 告警 。 


17.4.8” 限 流 


我 们 系统 中 存在 的 主要 限 流 逻辑 是 ， 对 于 大 多 数 请 求 按照 PP 请 求 数 限 
流 ， 对 于 登录 用 户 按 照 用 户 限 流 。 对 于 读 取 缓存 的 请 求 不 进行 限 流 ， 只 
对 打 到 后 端 系统 的 请 求 进行 限 流 。 还 可 以 限制 用 户 访 问 频率 ， 比 如 ， 使 
用 ngx_lua 中 的 ngx.sleep 对 请 求 进 行 体 眼 处 理 ， 让 刷 接口 的 速度 降下 来 。 
或 者 种 植 cookie token 之 类 的 ， 必 须 按照 流程 访问 。 当 然 还 可 以 对 疏 虫 / 刷 
数据 的 请 求 返 回 假 数 据 来 减少 影响 。 


17.5 “前 端 业务 逻 辑 后 置 


前 端 JS 应 该 尽 可 能 少 写 业 务 逻 辑 和 一 些 切 换 逻 辑 ， 因 为 前 端 JS 一 般 推 送 
到 CDN， 假 设 逻 辑 出 问题 了 ， 需 要 更 新 代 公 上线， 推送 到 CDN 然 后 让 各 
个 边缘 CDN 节 点 失效 ， 或 者 通过 版 本 号 机 制 在 服务 器 端 模 板 中 修改 版 本 
号 上 线 。 这 两 种 方式 都 存在 效率 问题 ， 假 设 处 理 一 个 紧急 故障 ， 用 这 两 
种 方式 处 理 的 过 程 中 可 能 故障 早已 经 恢复 了 。 因 此 ， 我 们 的 观点 是 前 端 
JS 只 拿 数据 展示 ， 所 有 或 大 部 分 逻辑 交 给 后 端 去 完成 ， 即 静态 资源 
CSS/JS CDN， 动 态 资 源 JSONP。 前端 J]S 瘦 身 ， 业 务 逻 辑 后 置 。 


在 “ 双 11” 期 间 我 们 的 某 些 服 务 出 问题 了 ， 不 能 更 新 商品 信息 ， 此 时 秒杀 商 
品 需 要 打 标 处 理 ， 因 此 我 们 在 服务 器 端 完 成 了 这 件 事情 ， 整 个 处 理 过 程 
只 需要 几 十 秒 束 能 搞定 ， 避 人 免 了 商品 不 能 被 秒杀 的 问题 。 而 如 有 果 在 JS 中 
完成 ， 则 需要 耗费 非常 长 的 时 间 ， 因 为 JS 在 客户 端 还 有 缓存 时 间 ， 而 且 
一 般 缓存 时 间 非 常 长 。 


17.6 “前端 接口 服务 咒 端 聚合 


商品 详情 页 上 依赖 的 服务 众多 ， 一 个 类 似 的 服务 需要 请 求 多 个 不 相关 的 
服务 接口 ， 造 成 前 端 代码 胱 肿 ， 判 断 逻 辑 众 多 。 而 我 们 无 法 忍受 这 种 现 
TK, 我们 想 要 的 结果 就 是 前 端 异步 请 求 一 个 API， 我 们 把 相关 数据 准备 好 
发 过 去 ， 前 端 直接 拿 到 数据 展示 即 可 。 所 有 或 大 部 分 逻辑 在 服务 器 端 完 
成 而 不 是 在 客户 问 完 成 。 因 此 ， 我 们 在 接 入 层 使 用 Lua 协 程 机制 并 发 调用 
多 个 相关 服务 ， 最 后 把 这 些 服务 进行 合并 ， 比 如 几 种 推荐 服务 : 最 佳 组 
合 、 推 荐 配件 、 人 优惠 套装 。 通过 http://c.3.cn/recommend? 
methods-accessories,suit, 

combination&sku-1159330&cat-6728,6740,12408&did-1&lim-63t £118 RIK 
E um 这 样 原 来 前 端 需 要 调用 三 次 的 接口 只 需要 一 次 束 能 吐出 


我 们 对 这 种 请 求 进行 了 API 封 装 ， 如 下 图 所 示 。 


if switch_get("accessories- spi. not. call”) “= “1” and methods['sccessories'] snd checkIsEnsbleAccess(skuId, cst[1], cat[2]) then 
r” 


5, 
args = "skuld-^ .. skuld .. "&ci-^ .. cat[1] .. "&c2-^ .. cat[2] .. "&c3-" .. cat[3] .. "&ares-^ .. area 


比如 库存 服务 ， 商 品 是 否 有 货 需 要 判断 : 主 商品 库存 状态 、 主 商品 对 应 
的 套装 、 子 商品 库存 状态 、 主 商品 附件 库存 状态 及 套装 子 商 品 附件 库存 
状态 。 套 骏 商 品 是 一 个 虚拟 商品 ， 是 多 个 商品 绑 定 在 一 起 进行 售卖 的 形 
式 。 如 果 这 段 逻 辑 放 在 前 段 完成 ， 则 需要 多 次 调用 库存 服务 ， 然 后 进行 
组 合 判断 ， 这 样 前 端 代码 会 非常 复杂 ， 凡 是 涉及 调用 库存 的 服务 都 要 进 
行 这 种 判断 。 因 此 ， 我 们 把 这 些 逻 辑 封 装 到 服务 端 完 成 。 前 端 请 求 
http://c0.3.cn/stock? 

skuld-1856581&venderId-0&cat-9987,653,655&area-1 72 2840 0&b 
uyNum=1&extraParam= 

{%22originid%22:%221%22} &ch-1&callback-getStockCallback, SARAH 
端 计算 整个 库存 状态 ， 而 前 端 不 需要 做 任何 调整 。 在 服务 端 使 用 Lua 协 程 
并 发 的 进行 库存 调用 ， 如 下 图 所 示 。 


查询 主 商 品 库 存 | 
L J | 主 商 品 + 子 商品 
| } f | | 库存 状态 合并 
查询 主 商品 对 应 的 附件 和 套装 子 商品 ， 及 套装 商品 的 附件 查询 子 商品 库存 


再 比如 今日 抄底 服务 ， 调 用 接口 太 多 ， 如 库存 、 价 格 、 促 销 等 都 需要 调 
用 ， 因 此 ， 我 们 也 使 用 这 种 机 制 把 这 几 个 服务 在 接 入 层 合并 为 一 个 大 服 
务 ; 对 外 Es [^i P http://c.3.cn/today? 
skuld=1264537&area=1_72_2840_0&promotionId=182369342&cat=737, 
752,760&callback=j Query9364459&_=1444305642364 ° 


我 们 目前 合并 的 主要 有 : 促销 和 广告 词 合并、 配送 至 相关 服务 合并 。 而 
未 来 这 些 服务 都 会 合并 ， 并 会 在 前 端 进行 一 些 特 殊 处 理 ， 比 如 设置 超 
时 ， 超 时 后 目 动 调用 原子 接口 。 接 口 吐 出 的 数据 状态 码 不 对 ， 再 请 求 一 
次 原子 接口 获取 相关 数据 。 


17.7 ”服务 隔离 


服务 隔离 的 目的 是 防止 因为 某 些 服务 拌 动 而 造成 整个 应 用 内 的 所 有 服务 
不 可 用 ， 可 以 分 为 应 用 内 线程 池 隔离 、 部 署 /分 组 隔离 、 拆 应 用 隔离 。 


` 应 用 内 线程 池 隔 离 : 我 们 采用 了 Servlet 3 异步 化 ， 并 为 不 同 的 请 求 按 照 
重要 级 别 分 配 线程 池 ， 这 些 线程 池 是 相互 隔离 的 ， 我 们 也 提供 了 监控 接 
口 以 便 发 现 问题 并 及 时 进行 动态 调整 ， 该 实践 可 以 参考 第 3 草 内 容 。 


` 部 署 /分 组 隔离 : 意思 是 为 不 同 的 消费 方 提供 不 同 的 分 组 ， 不 同 的 分 组 
之 间 相 互 不 影响 ， 以 免 因为 大 家 使 用 同一 个 分 组 导致 有 些 人 乱用 ， 和 致使 
整个 分 组 服务 不 可 用 。 


` 拆 应 用 隔离 : 如 果 一 个 服务 调用 量 巨大 ， 那 么 我 们 便 可 以 把 这 个 服务 单 
做 成 一 个 应 用 ， 减 少 因 其 他 服务 上 线 或 者 重启 导致 影响 本 应 


18 ”使 用 OpenResty 开 发 高 性 能 Web 应 
用 


在 互联 网 公司 ，Nginx 可 以 说 是 标 配 组 件 ， 但 是 主要 场景 还 是 负载 均衡 、 
反 向 代理 、 代 理 缓存 、 限 流 等 。 而 把 Nginx 作 为 一 个 web 容 需 使 用 的 还 不 
是 那么 广泛 。Nginx 的 高 性 能 是 大 家 公认 的 ， 而 Nginx 开 发 主要 是 以 
C/C++ 模块 的 形式 进行 ， 整 体 学 习 和 开发 成 本 偏 高 。 如 有 果 需 要 一 种 简单 的 
语言 来 实现 Web 应 用 的 开发 ， 那 么 Nginx 绝 对 是 个 好 选择 。 目 前 ，Nginx 团 
队 也 开始 意识 到 这 个 问题 ， 开 发 了 nginxScript， 可 以 在 Nginx 中 使 用 
JavaScript 进 行动 态 配 置 一 些 变量 和 动态 脚本 执行 。 而 目前 市 面 上 用 得 非 
常 成熟 的 扩展 是 由 章 亦 春 将 Lua 和 Nginx 条 合 的 ngx_lua 模 块 ， 并 且 将 Nginx 
核心 、LuaJIT、ngx_lua 模 块 、 许 多 有 用 的 Lua 库 和 常用 的 第 三 方 Nginx 模 
块 组 合 在 一 起 成 为 OpenResty， 这 样 开 发 人 员 就 可 以 安装 OpenResty， 使 
用 Lua 编 写 脚本 ， 然 后 部 署 到 Nginx Web 容 器 中 运行 ， 这 样 束 能 非常 轻松 
地 开发 出 高 性 能 的 Web 服 务 。 


接 下 来 ， 我 们 就 认识 一 下 构成 Open Resty 的 Nginx、Lua、ngx_lua 模 块 ， 
以 及 OpenResty 到 底 能 开发 哪些 类 型 的 Web 应 用 。 


18.1 OpenResty 人 简介 


18.1.1 Nginx 优 点 


Nginx 设 计 为 一 个 主 进程 多 个 工作 进程 的 工作 模式 ， 每 个 进程 是 单线 程 来 
处 理 多 个 连接 ， 而 且 每 个 工作 进程 采用 了 非 阻 蹇 IO 来 处 理 多 个 连接 ， 从 
而 减少 了 线程 上 下 文 切换 ， 实 现 了 公认 的 高 性 能 、 高 并 发 。 因 此 ， 在 生 
成 环境 中 会 通过 把 CPU 绑 定 给 Nginx 工 作 进 程 ， 从 而 提升 其 性 能 。 另 外 ， 
因为 单线 程 工作 模式 的 特点 ， 内 存 占 用 就 非常 少 了 。 


Nginx 更 改 配置 后 重 局 速度 非常 快 ， 可 以 达到 营 秒 级 ， 而 且 文 持 不 停止 
Nginxj 进 行 升级 Nginx 厂 本、 动态 重 载 Nginx 配 置 。 


Nginx 模 块 也 非常 多 ， 功 能 也 很 强劲 ， 不 仅 可 以 作为 HITP 有 负载 均衡 ， 
Nginx 发 布 1.9.0 版 本 还 文 持 TCP 负 载 均 衡 ， 还 可 以 很 容易 地 实现 内 容 组 
存 、Web 服 务 器 、 反 向 代理 、 访 问 控制 等 功能 。 


18.1.2 Lua 的 优点 


Lua 是 一 种 轻 量 级 、 可 拘 入 式 的 脚本 语言 ， 可 以 非常 容易 地 纳入 到 其 他 语 
言 中 使 用 。 男 外 ，Lua 提 供 了 协 程 并 发 ， 即 以 同步 调用 的 方式 进行 异步 执 
行 ， 从 而 实现 并 发 ， 比 起 回调 机 制 的 并 发 来 说 代码 更 容易 编写 和 理解 ， 
TEE IRIS s SE TE) ^ Lua $e Bt f WIESE, ERA RI DATEN First Class 
Value 进行 参数 传递 ， 另 外 ， 其 实现 了 标记 清除 垃圾 收集 。 


因为 ua 的 小 巧 轻 量 级 ， 可 以 在 Nginx 中 嵌入 Lua VM， 请 求 的 时 候 创建 一 
个 VM， 请 求 结束 的 时 候 回 收 VM ° 


18.1.3 ”什么 是 ngx_lua 


ngx_lua 是 章 亦 春 编写 的 Nginx 的 一 个 模块 ， 将 Lua 峙 入 到 Nginx 中 ， 从 而 可 
以 使 用 Lua 来 编写 脚本 ， 部 署 到 Nginx 中 运行 ， 即 Nginx 变 成 了 一 个 Web 容 
絮 。 这 样 开 发 人 员 就 可 以 使 用 Lua 语 言 开 发 高 性 能 Web 应 用 了 。 


ngx_lua 提 供 了 与 Nginx 交 互 的 很 多 API， 对 于 开发 人 员 来 说 只 需要 学 习 这 
些 API 就 可 以 进行 功能 开发 ， 而 对 于 开发 Web 应 用 来 说 ， 如 果 接 触 过 
Servlet 有 的话 ， 你 会 发 现 其 开发 和 Servlet 类 似 ， 无 外 平 束 是 知道 接收 请 求 、 
参数 解析 、 功 能 处 理 、 返 回 啊 应 这 几 步 的 API 是 什么 样子 的 。 


18.1.4 开发 环境 


我 们 使 用 OpenResty 来 搭建 开发 环境 ，OpenResty 将 Nginx 核 心 、LuaJIT、 
许多 有 用 的 Lua 库 和 Nginx 第 三 方 模块 打包 在 一 起 。 这 样 开 发 人 员 只 需要 
安装 OpenResty， 不 需要 了 解 Nginx 核 心 和 写 复杂 的 C/C++ 模 块 ， 只 需要 使 
用 Lua 语 言 进 行 Web 应 用 开发 。 


如 何 安 逆 可 扫 摘 下面 二 维 码 参考 笔者 写 的 《 跟 我 学 OpenResty 
(Nginx*Lua) 开发 》 教 程 。 


18.1.5 OpenResty^E S 


OpenResty 提 供 了 一 些 常用 的 ngx_lua 开 发 模块 ， 如 lua-resty-memcached、 
lua-restymysql ^ lua-resty-redis ^ lua-resty-dns ^ lua-resty-limit-traffic ^ lua- 
resty-template ° 


这 些 模块 涉及 如 MySQL 数 据 库 、Redis、 限 流 、 模 块 浑 染 等 常用 功能 组 
件 。 另 外 ， 也 有 很 多 第 三 方 的 ngx_lua 组 件 供 我 们 使 用 ， 对 于 大 部 分 应 用 
场景 来 说 ， 现 在 生态 环境 中 的 组 件 已 经 足够 多 了 “。 如 采 不 满足 需求 ， 那 
么 也 可 以 自己 去 写 来 完成 需求 。 


18.1.6 ”场景 


HBÜCDN/ 商 使 用 OpenResty 较 多 ， 而 像 京 东 有 使 用 OpenResty 开 发 复杂 
的 Web 应 用 。 目 前 见 到 的 一 些 应 用 场景 如 下 。 


. Web 应 用 : 会 进行 一 些 业务 逻辑 处 理 ， 甚 至 进行 耗 CPU 的 模板 泻 染 ， 一 
般 流程 包括 mysql/Redis/HTTP 获 取 数 据 、 业 务 处 理 、 产 生 JSON/XML/ 模 
板 泻 染 内 容 ， 比 如 ， 京 东 的 列表 页 /商品 详情 页 。 


接 入 网 关 : 实现 如 数据 校 验 前 置 、 缓 存 前 置 、 数 据 过 滤 、API 请 求 聚 
合 、A/B 测 试 、 灰 度 发 布 、 降 级 、 监 欣 等 功能 ， 比 如 ， 东 东 的 交易 大 
Nginx 世 点 、 无 线 部 门 正 在 开发 的 无 线 网 关 、 单 品 页 统一 服务 、 实 时 价 
格 、 动 态 服务 。 


- Web 防 火 墙 : 可 以 进行 IP/URL/UserAgent/Referer 黑 名 单 、 限 流 等 功能 。 


e ms 可 以 对 响应 内 容 进 行 缓存 ， 减 少 到 达 后 端的 请 求 ， 从 而 提 
TEBE ° 


ia 


O 〇 


入 略图 裁剪 


、 zi 


其 他 : 如 静态 资源 服务 器 、 消 息 推送 服务 


18.2 ”基于 OpenResty 的 常用 架构 模式 
18.2.1 ”负载 均衡 


如 下 图 所 示 ， 我 们 首先 通过 LVS+HAProxy 将 流量 转发 给 核心 Nginx 1 和 核 
心 Nginx 2， 即 实现 了 流量 的 负载 均衡 ， 此 处 可 以 使 用 如 轮 询 、 一 致 性 哈 
名 等 调度 算法 来 实现 负载 的 转发 。 然 后 核心 Nginx 会 根据 请 求 特征 
如 “Host:item.jd.com”， 转 发 给 相应 的 业务 Nginx 广 点， 如 单 品 页 Nginx 1。 
此 处 为 什么 分 两 层 呢 ? 


LVS+HAProxy 
y x 


核心 Nginx 1 | | 核心 Nginx 2 | 


首页 Nginx | | 单 品 页 Nginx1 | | 单 品 页 Nginx 2 


. 核心 Nginx 层 是 无 状态 的 ， 可 以 在 这 一 层 实现 流量 分 组 (内 网 和 外 网 隔 
离 、 扑 虫 和 非 候 虫 流量 隔离 、 内 容 缓 存 、 请 求 头 过 滤 、 故障 切 换 (机 
房 故障 切换 到 其 他 机 房 ) 、 限 流 、 防 火 墙 等 一 些 通 用 型 功能 。 

` 业务 Nginx， 如 单 咒 页 Nginx， 可 以 在 业务 Nginx 实 现 业 务 逻 辑 ， 或 者 反 
加 代理 到 如 Tomcat， 在 这 一 层 可 以 实现 内 容 压缩 ( 放 在 这 一 层 的 目的 是 
减少 核心 Nginx 的 CPU 压力 ， 将 压力 分 散 到 各 业务 Nginx) 、A/B 测 试 、 降 
级 。 即 这 一 层 的 Nginx 跟 业务 有 关联 ， 实 现 业 务 的 一 些 通用 逻辑 。 


不 管 是 核心 Nginx 还 是 业务 Nginx， 都 应 该 是 无 状态 设计 ， 可 以 水 平 扩 


容 ， 如 下 图 所 示 。 
单 品 页 Nginx 


意 品 页 Tomcat 1 | | 单 品 页 Tomcat 2 | 


业务 Nginx 一 般 会 把 请 求 直 接续 发 给 后 端的 业务 应 用 ， 如 Tomcat ` PHP, 
即将 请 求 内 部 转发 到 相应 的 业务 应 用 。 当 有 的 Tomcat 出 现 问题 时 ， 可 以 
在 这 一 层 搞 掉 。 或 者 有 的 业务 路 径 变 了 在 这 一 层 进行 重 写 。 或 者 有 的 后 
端 Tomcat 压 力 太 大 也 可 以 在 这 一 层 降级 ， 减 少 对 后 端 冲 击 。 或 者 业务 需 
要 灰 度 发 布 时 ， 也 可 以 在 这 一 层 Nginx 上 控制 。 


18.2.2 单机 闭环 


所 谓 单机 闭环 即 所 有 想 要 的 数据 都 能 从 本 服务 礁 中 直接 获取 ， 在 大 多 数 
时 候 无 须 通过 网 络 去 其 他 服务 器 获取 。 


如 下 图 所 示 ， 主 要 有 三 种 应 用 模式 。 


服务 器 192.168.1.2 服务 器 192.168.1.3 服务 器 192.168.1.4 
Nginx 应 用 p Nginx 应 用 ， p | Nginx H 一 
(Lua 程 序 ) 一 一 (Lua 程序 一 一 一 Lua 程序 F 
^ ee =a ) wg 9 ` Y 


Redis/Redis 焦 群 /SSDB 


/ 
| 久 件 系统 f 


左边 第 一 幅 图 的 应 用 场景 是 Nginx 应 用 谁 也 不 依赖 ， 比 如 ， 我 们 的 Cookie 
日 名 单 应 用 ， 其 目的 是 不 在 白 名 单 中 的 Cookie 将 被 清理 ， 防 止 大 家 随便 
将 Cookie 写 到 jd.om 根 下 ; 大 家 访问 http://www.jd.com 时 ， 会 看 到 一 个 
http://ccc.jd.com/cookie_check 的 请 求 用 来 清理 Cookie。 对 于 这 种 应 用 非常 
简单 ， 不 需要 依赖 数据 源 ， 直 接 单 应 用 闭环 即 可 。 


中 间 那 幅 的 场景 ， 是 读 取 本 机 文件 系统 ， 如 静态 资源 合并 。 比 如 ， 访 问 
http://item.jd.com/1856584.html， 查 看 源码 会 发 现 («link type="text/css" 
rel="stylesheet" href="//misc.360buyimg.com/jdf/1.0.0/unit/??ui-base/1.0.0/ui- 
base.css,shortcut/2.0.0/shortcut.css, global-header/1.0.0/global- 
header.css,myjd/2.0.0/myjd.css,nav/2.0.0/nav.css,shoppingcart/ 
2.0.0/shoppingcart.css,global-footer/1.0.0/global- 
footer.css,service/1.0.0/service.css"/») 这 种 请 求 ， 即 多 个 请 求 合 并 为 一 个 


发 给 服务 器 端 ， 服 务 器 端 进 行 了 文件 资源 的 合并 ， 如 下 图 所 示 。 


Http://jd.com/static??a.css,b.css,c.css 


Nginx/Lua Static Merger 


a.css C.CSS 


目前 有 成 熟 的 Nginx 模 块 (如 nginx-http-concat) 进行 静态 资源 合并 。 因 为 
我 们 使 用 了 OpenResty， 所 以 我 们 完全 可 以 使 用 Lua 编 写 程 序 实现 该 功 
能 ， 比 如 ， 已 经 有 人 写 了 nginx-lua-static-merger 来 实现 这 个 功能 。 


还 有 一 些 业 务 型 应 用 场景 如 下 图 所 示 。 


商品 页 面 是 由 商品 框架 和 其 他 维度 的 页 面 片段 (面包 悄 、 相 关 分 类 、 商 
家 信息 、 规 格 参数 、 商 品 详情 ) 组 成 。 或 者 首页 是 由 首页 框架 和 一 些 页 
面 片段 (分 类 、 轮 播 图 、 楼 层 1、 楼 层 N ) 组 成 。 分 维度 是 因为 不 同 的 维 
度 是 独立 变化 的 。 对 于 这 种 静态 内 容 需 要 进行 框架 内 容 答 入 ，Nginx 自 带 
的 SSI (Server Side Include) 可 以 很 轻松 地 完成 。 也 可 以 使 用 Lua 程 序 更 
灵活 地 完成 〈 读 取 框 架 、 读 取 页 面 片段 、 合 并 输出 ) 。 


比如 ， 商 品 页面 的 染 构 我 们 可 以 像 下 图 这 样 实现 。 


服务 器 192.168.1.3 
| Nginx 应 用 pec. 
— — uF 
Bec d 
商品 页 面 框架 
SA AS 相关 分 类 
PET sy Ty 全 s 
页 面 变更 消息 hes ae Ye tH 推送 | 商家 信息 xfi 
[3] 2b Worker 规格 参数 系统 
商品 详情 


首先 ， 接 收 到 商品 变更 消息 ， 商 品 页 面 同 步 Worker 会 根据 消息 维度 生成 
相关 的 页 面 ， 然 后 推送 到 Nginx 服 务 器 。Nginx 应 用 再 通过 SSI 输 出 。 目 前 
京东 商品 详情 页 没有 再 采用 这 种 架构 ， 上 有 具体 架构 可 以 参考 第 16 章 的 内 
容 。 


对 于 首页 的 架构 是 类 似 的 ， 因 为 其 特点 (框架 变化 少 ， 楼 层 变化 较 频 
SE) 和 个 性 化 的 要 求 ， 楼 层 一 般 实现 为 异步 加 载 。 


再 来 看 右边 那 幅 图 。 它 与 中 间 那 幅 图 的 不 同 之 处 是 不 再 直接 读 取 文 件 系 
统 ， 而 是 读 取 本 机 的 Redis， 或 者 Redis 集 群 ， 或 者 如 SSDB 这 种 持久 化 存 
储 ， 或 者 其 他 存储 系统 也 是 可 以 的 ， 比 如 之 前 说 的 商品 页 面 可 以 使 用 
SSDB 进 行 存储 实现 。 文 件 系 统 存 在 一 个 很 大 的 问题 ， 即 当 有 多 台 服 务 器 
上 时， 需要 Worker 去 写 多 台 服 务 器 ， 而 这 个 过 程 可 以 使 用 SSDB 的 主 从 实 
现 ， 如 下 图 所 示 。 


服务 器 192.168.1.3 服务 器 192.168.1.4 
Nginx 应 用 一 =L Nginx 应 用 一 
e ut? | Lua 程 序 入 
à à AN 2 Saw \ 
商品 页 面 框架 ) 商品 页 面 框 架 | 
相关 分 类 / 相关 分 类 m 
EENE PRA e 商家 信息 t 商家 信息 Se 
Danone 规格 参数 规格 参数 7 
商品 详情 bv 商品 详情 2 
be 


此 处 可 以 看 到 ， 不 管 是 中 间 图 还 是 右边 图 的 架构 ， 都 需要 Worker 进 行 数 
据 推送 。 假 设 本 机 数据 丢 了 怎么 办 ? 因为 有 这 个 潜在 问题 ， 实 际 大 部 分 
应 用 不 会 是 完全 单机 闭环 的 ， 而 是 会 采用 如 下 页 图 所 示 的 架构 。 


服务 器 192.168.1.3 服务 器 192.168.1.4 


2， 回 源 到 Web 应 用 
Nginx 应 用 Tomcat 应 用 L 
1. 读本 机 数据 库 / 服 务 总 线 
文件 系统 | 


数据 库 / 服 务 总 线 


LV9+HAProxy 


Es | 


主 Redis 集 群 


即 首 先 读本 机 ， 如 果 没 数据 ， 则 会 回 产 到 相应 的 Web 应 用 ， 从 数据 源 拉 取 
原始 数据 进行 处 理 。 这 种 架构 的 大 部 分 场景 本 机 都 可 以 命中 数据 ， 只 
很 少 一 部 分 情况 会 回 源 到 Web 应 用 。 


如 京东 的 实时 价格 /动态 服务 就 是 采用 类 似 架 构 。 
18.2.3 ”分 布 式 闭环 

单机 闭环 会 遇 到 如 下 两 个 主要 问题 ， 数 据 不 一 致 问题 (比如 ， 没 有 采用 
主 从 架构 导致 不 同 服务 器 数据 不 一 致 ，》， 存 储 瓶 颈 问题 (磁盘 或 者 内 存 
BATRE) 。 


解决 数据 不 一 致 的 比较 好 的 办 法 是 采用 主 从 或 者 分 布 式 集中 存储 。 而 中 
到 存储 竹 须 束 需 要 进行 按照 业务 键 进行 分 厂 ， 将 数据 分 散 到 多 台 服 务 
für o 


如 采用 如 下 页 图 所 示 的 架构 ， 按 照 尾 号 将 内 容 分 布 到 多 台 服 务 器 中 。 


核心 Nginx 


服务 器 192.168.1.2 服务 器 192.168.1.10 


Nginx 应 用 Nginx 应 用 


1，、 读 取 JIMD8 焦 群 


服务 器 192.168.1.1 


JIMDB4E ff 


Tomcat 应 用 集群 


第 一 步 先 读 取 分 布 式 存储 JIMDB 是 京东 的 一 个 分 布 式 缓存 /存储 系统 ， 
类 似 于 Redis) 。 如 果 不 命中 ， 则 回 源 到 Tomcat 集 群 (其 会 调用 数据 库 、 
服务 总 线 获取 相关 数据 ， 来 获取 相关 数据 。 可 以 参考 第 16 章 的 内 容 来 获 
取 更 详细 的 架构 实现 。 


JIMDB 集 群 会 进行 多 机 房 主 从 同步 ， 各 目 机 房 读 取 目 己 机 房 的 从 JIMDB 
集群 ， 如 下 图 所 示 。 


Nginx+Lua 
从 Redis 集 群 
Nginx+Lua 
LVS+HAProxy 
Nginx+Lua 
从 Redis 集 群 
Nginx+Lua 


更 新 缓存 同步 


18.2.4 RAM 


接 入 网 关 也 可 以 叫做 接 入 层 ， 即 接收 到 流量 的 入 口 ， 在 入 口 我 们 可 以 进 
行 如 下 页 图 所 示 的 操作 。 


核心 接 入 Nginx | 核心 接 入 Nginx 


L— 


| 业务 接 入 Nginx | 7 | 业务 接 入 Nginx 

/ “Local Cache ` , “Local Cache N 

| or | or 

\ Proxy Cache / | _ Proxy Cache 
dint 


1 


Redis 集 群 


Tomcat 集 和 群 


1. 核 心 接 入 Nginx 功 能 


: 动态 负载 均衡 : 普通 流量 使 用 一 致 性 哈 希 ， 提 升 命中 率 。 热 点 流量 走 轮 
询 减 少 单 服务 器 压力 。 根 据 请 求 特征 将 流量 分 配 到 不 同 分 组 并 限 流 (KE 
虫 或 者 流量 大 的 IP) 。 动 态 流 量 (动态 增加 upstream ， 或 者 减少 
upstream， 或 者 动态 负载 均衡 ) 可 以 使 用 balancer_by_lua， 或 者 微 博 开 源 
的 upsync ° 


` 防 DDoS 攻 击 限 流 : 可 以 将 请 求 日 志 推 送 到 实时 计算 集群 ， 然 后 将 需要 
限 流 的 IP 推 送 到 核心 Nginx 进 行 限 流 。 

. 非法 请 求 过 滤 : 比如 ， 应 该 有 Referer 却 没有 ， 或 者 应 该 带 着 Cookie 却 没 
有 Cookie ° 

. 请 求 聚合 :比如 请 求 的 是 http:/c.3.cn/proxy?methods=abc， 核 心 接 入 
Nginx 会 在 服务 端 把 Nginx 的 并 发 请 求 并 把 结果 聚合 然后 一 次 性 吐出 。 


` 请 求 头 过 滤 : 有 些 业 务 是 不 需要 请 求 头 的 ， 因 此， 可 以 在 往 业 务 Nginx 
转发 时 把 这 些 数据 过 滤 掉 。 


. 缓存 服务 使 用 Nginx Proxy Cache 实 现 内 容 页面 的 缓存 。 
2. 业 务 Nginx 功 能 


` 缓存 对 于 读 服务 会 使 用 大 量 的 缓存 来 提升 性 能 ， 我 们 在 设计 时 主要 有 
如 下 缓存 应 用 。 首 先 ， 读 取 Nginx 本 地 缓存 Shared Dict 或 者 Nginx Proxy 
Cache， 如 果 有 ， 则 直接 返回 内 容 给 用 户 。 如 有 果 本 地 缓存 不 命中 ， 则 会 读 
取 分 布 式 缓存 如 Redis， 如 果 有 ， 则 直接 返回 。 如 有 果 还 是 不 命中 ， 则 回 源 
人 。 另 外， 我 们 会 按照 维度 进行 
数据 缓存 。 


-业务 逻辑 : 我 们 会 进行 一 些 数 据 校 验 /过 滤 逻 辑 前 置 “如 商品 ID 必须 是 
AF) 、 业 务 逻 辑 前 置 (获取 原子 数据 ， 然 后 在 Nginx 上 写 业 务 逻 辑 ) 。 


: 细 粒 度 限 流 : 按照 接 口 特征 和 接口 吞吐 量 来 实现 动态 限 流 ， 比 如 ， 后 端 

服务 快 打 不 住 了 ， 那 我 们 就 需要 进行 限 流 ， 被 限 流 的 请 求 作为 降级 请 求 

处 理 。lua-resty-limitrtraffic 可 以 通过 编程 实现 更 灵活 的 降级 逻辑 ， 如 根据 

用 户 、 根 据 UREL 等 各 种 规则 ， 如 降级 了 是 让 用 户 请 求 等 待 〈 比 如 sleep 

这 样 用 户 请 求 就 慢 下 来 了 ， 但 是 服务 还 是 可 用 的 ) 还 是 返回 降级 
容 。 


ER: 降级 主要 有 主动 降级 和 被 动 降级 两 种 。 如 果 请 求 量 太 大 打 不 住 
了 ， 那 我 们 需要 主动 降级 。 如 果 后 端 挂 了 或 者 被 限 流 了 或 者 后 端 超时 
了 ， 那 我 们 需要 被 动 降级 。 降 级 方案 包括 返回 默认 数据 ， 如 库存 默认 有 
货 ; 返回 静态 页 ， 如 预先 生成 的 静态 页 ， 对 部 分 用 户 降 级 ， 告 诉 部 分 用 
户 等 竺 下 再 操作 ; 直接 降级 ， 服 务 没 数据 ， 比 如 商品 页 面 的 规格 参数 不 
展示 ;只 降级 回 源 服务 ， 即 可 以 读 取 缓存 的 数据 返回 ， 实 现 部 分 可 用 ， 

但 是 不 会 回 源 处 理 。 


. A/B 测 斌 和 灰 度 发 布 ， 比 如， 要 上 一 个 新 的 接口 ， 可 以 在 业务 Nginx 通 
过 Lua 写 复杂 的 业务 规则 实现 不 同 的 人 看 到 不 同 的 版 本 。 


. 服务 质量 监控 : 我 们 可 以 记录 请 求 响应 时 间 、 缓 存 响 应 时 间 、 反 向 代理 
服务 响应 时 间 来 详细 了 解 到 底 哪 块 服务 慢 了 。 男 外 ， 记 录 非 200 状 态 码 错 
DOR TERRAS AT HIS o 


京东 的 交易 大 Nginx 世 点 、 无 线 部 门 正在 开发 的 无 线 Nginx 网 关 和 单 品 页 
而 单 品 页 统一 服务 染 构 可 以 参考 第 17 草 
` 谷 o 


18.2.5 ”Web 应 用 


此 处 所 说 的 Web 应 用 指 的 古 页 面 模 板 泻 染 类 型 应 用 或 者 API 服 务 类 型 应 
用 。 比 如 ， 系 东 列 表 页 和 商品 详情 页 殉 是 一 个 模板 泻 染 类 型 的 应 用 ， 核 
心 业务 逻辑 都 是 使 用 Lua 写 的 ， 部 署 到 Nginx 容 器。 目前 核心 业务 代码 行 
数 有 5000 多 行 ， 模 板 页 面 有 2000 多 行 ， 涉 及 大 量 的 计算 逻辑 ， 性 能 数据 
可 以 参考 第 16 章 的 内 容 ”。 


如 下 页 图 所 示 ， 整 体 处 理 过 程 和 普通 Web 应 用 没什么 区 别 。 首 先 ， 接 收 请 
求 并 进行 解析 ; 然后 读 取 JIMDB 集 群 数据 ， 如 果 没 有 ， 则 回 源 到 Tomcat 
获取 ; 最 后 进行 业务 逻辑 处 理 ， 演 染 模 板 ， 将 啊 应 内 容 运 回 给 用 户 。 


核心 接 入 Nginx 


Am | 


、 请 求解 析 / 1、 请 求解 析 
^ — ——H—— —— HB l 
、 读 取 JIMDB/ 回 源 Tomcat 2、 读 取 JIMDB/ 回 源 Tomcat 
单 = 一 
、 业 务 处 理 品 Lua | 3、 业 务 处 理 
页 Ag i 
Nginx 4、 演 染 模板 
pL 
5、 返 回响 有 


JIMDB 集 群 


Tomcat 集 群 


18.3 ”如 何 使 用 OpenResty 开 发 Web 应 用 


T Ball TEZAT EE ` DEF ` ERIS LT EE 


1831 项目 搭建 
/export/App/nginx-app 
------- bin( 脚 本 ) 


CE start.sh 


(— PÉÀ nginx product.conf 
— resources.properties 
oe luaQlh 25 f C83) 

------------ init.lua 

— product controller.lua 
------ template( 模 板 ) 
— prodoct.html 

——À lualib( 公 共 Lua 库 ) 
------------ jd 

——— product. util.lua 


eee NOE EE product_data.lua 


template.lua 


整个 项 目 结构 从 局 停 脚 本 、 配 置 文件 、 公 共 组 件 、 业 务 代 码 、 模 板 代 码 


儿 块 进行 划分 。 


18.3.2 ” 启 停 脚本 


启 停 脚本 放 在 项 目 目 录 /export/App/nginx-app/bin/ 下 。 
start.sh 是 启动 和 更 新 脚本 ， 即 如 果 Nginx 没 有 启动 ， 则 启动 起 来 ， 否 则 重 


新 加 载 。 


sudo /export/servers/nginx/sbin/nginx 
config/nginx.conf 
sudo /export/servers/nginx/sbin/nginx 
config/nginx.conf 
else 
sudo /export/servers/nginx/sbin/nginx 
sudo /export/servers/nginx/sbin/nginx 
end 


stop.sh 是 停止 Nginx 的 脚本 。 


sudo /export/servers/nginx/sbin/nginx  -s quit 


18.3.3 ”配置 文件 


-t -c /export/App/nginx-app/ 


-c /export/App/nginx-app/ 


—E 
-s reload 


配置 文件 放 在 /export/App/nginx-app/config 目 录 下 ， 包 括 nginx.conf 配 置 文 


件 、Nginx 项 目 配置 文件 和 资源 配置 文件 。 
18.3.4 Nginx.conf 配 置 文件 


worker processes 1; 


events { 
worker connections 1024; 
} 
http { 
include mime.types; 
default type text/html; 
#gzip 相关 
# 超 时 时 间 
# 日 志 格式 
# 反 向 代理 配置 


#Lua 依赖 路 径 
lua package path  "/export/App/nginx-app/lualib/?.1ua;;"; 
lua package cpath  "/export/App/nginx-app/lualib/?.so;;"; 


#server 配置 
include /export/App/nginx-app/config/domains/*; 


# 初 始 化 脚本 
init by lua file "/export/App/nginx-app/lua/init.lua"; 
} 


对 于 nginx.conf 会 进行 一 些 通用 的 配置 ， 如 工作 进程 数 、 超 时 时 间 、 压 
缩 、 日 志 格 式 、 反 向 代理 等 相关 配置 。 男 外 ， 需 要 指定 如 下 配置 。 


.lua_package_path、lua_package_cpath: 指定 我 们 依赖 的 通用 Lua 库 从 
哪里 加 载 。 


- include /export/App/nginx-app/config/domains/*: 用 于 加 载 Server 相 天 
配置 ， 此 处 通过 * 可 以 在 一 个 Nginx 下 指定 多 个 Server 配 置 。 


- init by. lua file "/export/App/nginx-app/lua/init.lua": 执行 项 目的 一 些 
初始 化 配置 ， 比 如 加 载 配 置 文件 。 


18.3.5 ”Nginx 项 目 配 置 文件 


/export/App/nginx-app/config/domains/nginx_product.conf 用 于 配置 当前 Web 
应 用 的 一 些 Server 相 关 配 置 。 


#upstream 

upstream item http upstream { 
server 192.168.1.1 max fails-2 fail timeout-30s weight-5; 
server 192.168.1.2 max fails-2 fail timeout-30s weight-5; 


HET 
lua shared dict item local shop cache 600m; 
server { 
listen 80; 
server name item.jd.comtem.jd.hk; 
# 模 板 文件 从 哪 加 载 
set Stemplate root "/export/App/nginx-app/template "; 
#URL 映射 
location ~* "^/product/(Nd*)N.html$" { 


rewrite /product/(.*) http://item.jd.com/$1 permanent; 
} 
location ~* "^/(Nd(6,12))N.html1$" { 
default type text/html; 
charset gbk; 
lua code cache on; 
content by lua file 
"/export/App/nginx-app/lua/product controller.lua"; 
} 
} 


我 们 需要 指定 如 upstream、 共 享 字典 配置 、Server 配 置 、 模 板 文件 从 哪 加 
载 、URL 上 映射， 比如 我 们 访问 http:Vitem.jd.com/1856584.html 将 交 
Z5 /export/App/nginx-app/lua/ product_controllerlua 来 处 理 ， 也 就 是 说 我 们 
项 目的 入 口 就 有 了 ° 


资源 配置 文件 resources.properties 包 含 了 我 们 的 一 些 比如 开关 的 配置 、 缓 
存 服务 器 地 址 的 配置 等 。 


18.3.6 ”业务 代码 


/export/App/nginx-app/lua/ 目 录 里 存放 了 我 们 的 Lua 业 务 代 码 ，init.lua 用 于 
读 取 如 resources.properties 来 进行 一 些 项 目 初始 化 。product_controllerlua 可 
以 看 成 Java Web 中 的 Servlet， 用 来 接收 、 人 处理 、 响 应 用 户 请 求 。 


18.3.7 ”模板 


模板 文件 放 在 /export/App/nginx-app/template/ 目 好 下 ， 使 用 相应 的 模板 引 
擎 进行 编写 页 面 模 板 ， 然 后 演 染 输出 。 


18.3.8 ”公共 Lua 库 


存放 了 一 些 如 Redis、Template 等 相关 的 公共 Lua 库 ， 还 有 一 些 我 们 项 目 中 
通用 的 工具 库 如 product_utillua。 


至 此 一 个 简单 的 项 目 结构 就 介绍 完了 ， 对 于 开发 一 个 项 目 来 说 ， 还 会 涉 


及 分 模块 等 工作 ， 不 过 ， 对 于 我 们 这 种 Lua 应 用 来 说 ， 建 议 不 要 过 度 抽 
象 ， 尽 量 小 巧 即 可 。 


18.3.9 ”功能 开发 
接 下 来 ， 就 需要 使 用 相应 的 API 来 实现 我 们 的 业务 了 ， 比 如 


product_controller.lua ° 

-- 加 载 Lua 模 块 库 

local template = require("resty.template") 
--1. 获 取 请 求 参数 中 的 商品 ID 

local skuld = ngx.req.get_uri_args()["skuld"]; 
--2. 调 用 相应 的 服务 获取 数据 

local data = api.getData(skuld) 


--3. 演 染 模 板 


local func = template.compile("product.html") 
local content = func(data) 
--4. 通 过 ngx API 输 出 内 容 


ngx.say(content) 


开发 完成 后 将 项 目 部 署 到 测试 环境 ， 执 行 start.sh 局 动 Nginx， 然 后 进行 测 

试 。 详 细 的 开发 过 程 和 API 的 使 用 ， 请 参考 《 跟 我 学 OpenResty 
(Nginx*Lua) 开发 》， 此 处 不 做 具体 编码 实现 。 知 要 参考 源码 请 访问 

https://github.com/zhangkaitao/openrestyhelloworld ° 


18.4 ”基于 OpenResty 的 常用 功能 总 结 


到 此 我 们 对 于 Nginx 开 发 已 经 有 了 一 个 整体 认识 ， 将 Nginx 釉 合 Lua 来 开发 
应 用 可 以 说 是 一 把 锋利 的 瑞士 军刀 ， 可 以 帮 我 们 很 容易 地 解决 很 多 问 
题 ， 可 以 开发 Web 应 用 、 接 入 网 关 、API 网 关 、 消 息 推送 、 日 志 采 集 等 应 
用 ,不 过， 个 人 认为 适合 开发 业务 逻辑 单一 、 核 心 代码 行 数 较 少 的 应 
用 ， 不 适合 业务 逻辑 复杂 、 功 能 繁多 的 业务 型 或 者 企业 级 应 用 。 最 后 我 
们 总 结 一 下 基于 Nginx+Lua 的 常用 架构 模式 中 的 一 些 常见 实践 和 场景 ， 包 
括 : 动态 负载 均衡 、 防 火 墙 (DDoS、IP/URL/UserAgenUVReferer 黑 名 单 、 
防盗 链 等 ) 、 限 流 、 降 级 、A/B 测 试 和 灰 度 发 布 、 多 级 缓存 模式 、 服 务 需 
端 请 求 聚 合 、 服 务 质量 监控 。 


18.5 ”一些 问题 
. 在 开发 Nginx 应 用 时 ， 使 用 UTF-8 编 码 可 以 减少 很 多 麻烦 。 
. GBK 转 码 解码 时 ， 应 使 用 GB18030， 否 则 一 些 特殊 字符 会 出 现 乱码 © 


MAE 的 unicode 转 码 会 失败 ， 可 以 使 用 纯 Lua 编 写 
Jdkjson ° 


.社区 版 Nginx 不 文 持 upstream 的 域名 动态 解析 ， 可 以 考虑 proxy_pass 

(http://p.3.local/prices/mgets$is_args$args) ， 然 后 配合 resolver 来 实现 。 或 
者 在 Lua 中 进行 HTTP 调用。 如果 DNS 遇 到 性 能 瓶颈 ， 则 可 以 考虑 在 本 机 
部 署 如 dnsmasdq 来 缓存 ， 或 者 考虑 使 用 balancer_ by _lua 功 能 实现 动态 


upstream ° 
- 为 啊 应 添加 处 理 服务 器 耳 的 啊 应 头 ， 方 便 定 位 问题 。 
.根据 业务 设置 合理 的 超时 时 间 。 


-运行 CDN 的 业务 ， 当 发 生 错误 时 ， 不 要 给 返回 的 500/503/302/301 等 非 正 
和 常 响应 设置 缓存 。 


19 ”应 用 数据 静态 化 架构 高 性 能 单 页 
Web 应 用 


在 电 商 网 站 中 ， 单 页 Web 是 非常 常见 的 一 种 形式 ， 比 如 首页 、 频 道 页 、 广 
告 页 等 都 属于 单 页 应 用 。 而 这 种 页 面 是 由 模板 + 数据 组 成 的 。 传 统 的 构建 
方式 一 般 通过 静态 化 实现 ， 但 这 种 方式 的 灵活 性 并 不 是 很 好 ， 比 如 ， 页 
面 模 板 部 分 变更 了 需要 重新 全 部 生成 。 因 此 ， 最 好 能 有 一 种 实现 方式 是 
以 文 持 模 板 的 多 变性 。 另 外 也 要 考虑 好 如 下 几 个 
问题 。 


-动态 化 模板 渔 染 文 持 。 


` 数据 和 模板 的 多 版 本 化 : 生产 版 本 、 灰 度 版 本 和 预 发 布 版 本 。 


人 oe 
M : 


常 问题 ， 假 设 泻 染 模板 时 ， 遇 到 了 异常 情况 (比如 获取 Redis 出 问题 
， 该 如 何 处 理 。 


E 
T) 
. 灰 度 发 布 问题 ， 比 如 切 20% 量 给 灰 度 版 本 。 

. 预 发 布 问题 ， 目 的 是 在 正式 环境 测试 数据 和 模板 的 正确 性 。 


19.1 整体 架构 


静态 化 页 面 的 方案 如 下 图 所 示 。 
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推送 


直接 将 生成 的 静态 页 推送 到 相关 服务 器 上 即 可 。 使 用 这 种 方式 要 考虑 文 
m MS ( 即 从 老 版 本 切换 到 新 版 本 如 何 做 到 文件 操作 原子 


而 动态 化 方案 的 整体 架构 如 下 图 所 示 ， 分 为 三 大 系统 :CMS 系统、 控制 
系统 和 前 端 展示 系统 。 


接 入 层 Nginx 
192.168.1.1 192.168.1.2 


控制 系统 — P" 控制 版 本 前 端 展 示 系 统 


m 读 从 
发 布 数据 存储 
a -发 布 
存储 元 数据 


元 数据 存储 
MySQL 


19.1.1 CMS 系统 
在 CMS 系统 可 以 配置 页 面 的 模板 和 数据 。 


. 模板 动态 在 CMS 系统 中 维护 ， 即 模板 不 是 一 个 静态 文件 ， 而 是 存储 在 
CMS 中 的 一 条 数据 ， 最 终 发 布 到 "发布 数据 存储 Redis* 中 ， 前 端 展示 系统 
从 Redis 中 获取 该 模板 进行 泻 染 ， 从 而 前 端 展示 系统 更 换 了 模板 也 不 需要 
重启 ， 纯 动态 维护 模板 数据 。 


原始 数据 存储 到 “元 数据 存储 MySQL” 中 即 可 ， 比 如 ， 频 道 页 一 般 需 要 前 
端 访 问 的 URL、 分 类 、 轮 播 图 、 商 品 楼 层 数 据 等 。 这 些 数 据 按照 相应 的 
维度 存储 在 CMS 系 统 中 。 


` 提供 发 布 到 “发 布 数据 存储 Redis” 的 控制 ， 将 CMS 系 统 中 的 原始 数据 和 模 
板 数据 组 三 成 聚合 数据 (JSON 存 储 ) 同步 到 “发 布 数据 存储 Redis”， 以 便 
前 端 展 示 系 统 获取 进行 展示 。 此 处 提供 三 个 发 布 按钮 : 正式 版 本 、 灰 度 
版 本 和 预 发 布 版 本 。 


目前 存在 如 下 儿 个 问题 。 


“用户 如 访问 http://channel.jd.com/fashion.html， 怎 么 定位 到 对 应 的 聚合 交 
据 呢 ?我 们 可 以 在 CMS 元 数据 中 定义 URL 作 为 key， 如 果 没 有 URL， 则 使 
用 ID 作为 key， 或 者 自动 生成 一 个 URL 。 


- 多 版 本 如 何 存 储 呢 ?使 用 Redis 的 Hash 结 构 存 储 即 可 ，key 为 URL (比如 
http://channel.jd.com/fashion.html) ， 字 上 段 按照 维度 存储 正式 版 本 使 用 当 
前 时 间 惟 存储 (这样 前 端 系 统 可 以 根据 时 间 礁 排序 ， 然 后 获取 最 新 版 
AN) 、 预 发 布 版 本 使 用 “predeploy” 作 为 字段 ， 灰 度 版 本 使 用 “abVersion” 作 
为 字段 即 可 ， 这 样 就 区 分 开 了 多 版 本 。 


- 灰 度 版 本 如 何 控 制 呢 ? 可 以 通过 控制 系统 的 开关 来 控制 如 何 灰 度 。 


.如何 访 问 预 发布 版 本 呢 ? 比如， 在 URL 参 数 中 常 加 上 predeploy=true， 男 
外 ， 可 以 限定 只 有 内 网 可 以 访问 或 者 访问 时 加 上 访问 密码 ， 比 如 
pwd=absdfedwqdqw ° 

如 何 处 理 模 板 变 更 的 历史 数据 校 验 问题 ? 比如 模板 变更 了 ， 但是， 使 用 
历史 数据 泻 染 该 模板 会 出 现 问题 ， 即 模板 要 兼容 历史 数据 的 。 此 处 的 方 
案 不 存在 这 个 问题 ， 因 为 每 次 存储 时 是 当时 的 模板 快照 ， 即 数据 快照 和 
模板 快照 推送 到 “发 布 数据 存储 Redis” 中 。 


19.1.2 前端 展示 系统 
,获取 当前 URL， 使 用 URL 作 为 key 首 先 从 本 机 发布 数 据 存储 Redis' 获 取 


如果 没有 数据 或 者 异常 ， 则 从 主 “ 发 布 数 据 存储 Redis” 获 取 。 


如 果 主 “发 布 数据 存储 Redis” 也 发 生 了 异常 ， 那 么 会 直接 调用 CMS 系 统 骏 
圳 的 API， 直 接 从 元 数据 存储 MySQL 中 获取 数据 进行 处 理 。 


展示 系统 的 伪 代 码 
--1. 加 载 Lua 模 块 库 


local template = require("resty.template") 


template.load = function(s) return s end 


--2. 动 态 获取 模板 

local myTemplate = "<html> {* title *}</html>" 
--3. 动 仿 获取 数据 

local data = {title = "iphone6s"} 

--4 E RAL 

local func = template.compile(myTemplate) 
local content = func(data) 

--5. 通 过 ngx API 输 出 内 容 

ngx.say(content) 


即 模板 和 数据 部 吓 动态 获取 的 ， 然后 使 用 动态 获取 的 模板 和 数据 进行 泻 
Yu o 


AN 


假设 最 新 版 本 的 模板 或 数据 有 问题 怎么 办 ? 可 以 从 流程 上 避免 这 个 问 
Ji. 首先 进行 预 发 布 版 本 发 布 ， 测 试 人 员 验 证 没 问 题 后 ， 接 着 发 布 灰 度 
版 本 ;在 灰 度 时 目 动 去 掉 CDN 功 能 〈“ 即 不 设置 页 面 的 缓存 时 间 ) ， 发 布 
验证 没 问题 后 ， 发 布 正式 版 本 即 可 ; 正式 版 本 发 布 的 5 分 钟 内 是 不 设置 页 
面 缓存 的 ， 这 样 就 可 以 防止 发 版 时 过 到 问题 但是， 问题 版 本 已 经 在 
CDN 上 给 全 部 用 户 造成 问题 了 。 当 然 这 个 流程 很 矿 烦 ， 可 以 按照 目 己 的 
场景 进行 简化 。 


19.1.3 ”控制 系统 


控制 系统 用 于 版 本 降级 和 灰 度 发 布 ， 当 然 可 以 把 这 个 功能 放 在 CMS 系统 
中 实现 。 


-版 本 降级 : 假设 当前 线 上 的 版 本 遇 到 问题 ， 想 要 快速 切换 回 上 一 个 版 
本 ， 可 以 使 用 控制 系统 实现 ， 选 中 其 中 一 个 历史 版 本 ， 然 后 通知 给 前 端 
展示 系统 即 可 ， 使 用 URL 和 当前 版 本 的 字段 即 可 ， 这 样 前 端 展示 系统 束 
可 以 目 动 切换 到 选中 的 那个 版 本 。 当 问题 修复 后 ， 再 删除 该 降级 配置 ， 
即 切换 回 最 新 版 本 。 


KERM: 在 控制 系统 中 控制 哪些 URL 需 要 灰 度 发 布 ， 以 及 灰 度 发 布 的 
比例 ， 同 版 本 降级 类 似 将 相关 的 数据 推送 到 前 端 展示 系统 ， 当 不 想 灰 度 
发 布 时 ， 删 除 相 关 数 据 即 可 。 


19.2 ”数据 和 模板 动态 化 


我 们 将 数据 和 模板 都 进行 动态 化 存储 ， 这 样 可 以 在 CMS 进行 数据 和 模板 
的 变更 。 实 现 前 端 和 后 端 开 发 人 员 的 分 离 。 前 端 开 发 人 员 进 行 CMS 数据 
配置 和 模板 开发 ， 而 后 端 开发 人 员 只 进行 系统 维护 。 男 外 ， 因 为 模板 的 
动态 化 存储 ， 每 次 发 布 新 的 模板 不 需要 重 局 前 端 展示 系统 ， 后 端 开 发 人 
员 更 好 地 得 到 了 解放 。 

模板 和 数据 可 以 是 一 对 多 的 关系 ， 即 一 个 模板 可 以 被 多 个 数据 使 用 。 当 
模板 发 生变 更 后 ， 我 们 可 以 批量 推送 模板 关联 的 数据 。 首 先 ， 进 行 预 发 
布 版 本 的 发 布 ， 测试 人 员 进 行 验 证 ， 验 证 没 问题 即 可 发 布 正式 版 本 。 


19.3 ”多 版 本 机 制 


我 们 将 数据 和 模板 分 为 多 版 本 后 可 以 实现 如 下 几 点 。 
` 预 发 布 版 本 : 更 容易 让 测试 人 员 在 实际 环境 中 进行 验证 。 
KERE: 只 需要 简单 的 开关 控制 ， 就 可 以 进行 A/B 测 试 。 


` 正式 版 本 : 存储 多 个 历史 正式 版 本 ， 假 设 最 新 的 正式 版 本 出 现 问题 ， 可 
以 非常 快速 地 切换 回 之 前 的 版 本 。 


19.4 ”异常 问题 


常见 的 几 种 异常 如 下 。 


. 本 机 从 “发 布 数据 存储 Redis”" 和 主 “ 发 布 数据 存储 Redis” 都 不 能 用 了 ， 那 
么 ， 可 以 直接 调用 CMS 系统 暴露 的 HITP 服 务 ， 直 接 从 元 数据 存储 
MySQL 获 取 数 据 。 


.数据 和 模板 获取 到 了 ， 但 是 泻 染 模板 出 错 了 ， 比 如 遇 到 500、503。 解 决 
方案 是 使 用 上 一 个 版 本 的 数据 进行 泻 染 。 


` 数据 和 模板 都 没 问题 ， 但 是 因为 一 些 踊 包 ， 泻 染 出 来 的 页 面 错 乱 了 ， 或 
者 有 些 区 域 出 现 了 空白 。 对 于 这 种 问题 没有 很 好 的 解决 方案 。 可 以 根据 
目 己 的 场景 定义 异 稼 扫 摘 库 ， 扫 描 到 当前 版 本 有 有 弄 常 束 发 警告 给 相关 人 
员 ， 并 目 动 降级 到 上 一 个 版 本 。 


20 ”使 用 OpenResty 开 发 Web 服 务 


本 文 所 说 的 HTTP 服务 主要 指 如 访问 系 东 网 站 时 我 们 看 到 的 热门 搜索 、 用 
户 登 录 、 实 时 价格 、 实 时 库存 、 服 务 文 持 、 广 告 语 等 这 种 非 Web 页 面 ， 这 
些 是 在 如 商品 详情 页 中 异步 加 载 的 相关 数据 ， 它 们 有 个 特点 一 一 访问 量 
巨大 、 逻 辑 比较 单一 。 但 是 ， 实 时 库存 逻辑 其 实 是 非常 复杂 的 。 在 系 东 
这 些 服务 每 天 有 几 亿 、 十 几 亿 的 访问 量 。 比 如 ， 实 时 库存 服务 曾经 在 没 
有 任何 IP 限 流 、DDoS 防 御 的 情况 被 刷 到 600 多 万 /分 钟 的 访问 量 ， 仍 然 能 
轻松 应 对 。 文 撑 如 此 大 的 访问 量 ， 殊 需要 考虑 设计 民 好 的 架构 ， 并 确保 
很 容易 实现 水 平 扩展 。 


20.1 架构 


此 处 介绍 一 下 笔者 曾 使 用 过 的 OpenResty+JavaEE 技 术 架 构 。 
20.2 单 DB 架 构 


| Nginx | 
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Ic *mTomcat 


DDB 


Mysal 
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增加 新 的 Tomcat 实 例 ， 然 后 通过 Nginx 负 载 均 衡 upstream 过 去 ， 此 时 数据 
库 还 不 是 新 贷 。 当 访问 量 到 一 定 级 别 ， 数 据 库 的 压力 束 上 来 了 ， 此 时 单 
d E 可 以 通过 数据 库 的 读 写 分 离 或 加 缓存 来 
NX e 


20.2.1 DB+Cache/ 数 据 库 读 写 分 离 架 构 


外 负载 到 后 端 Tomcat 


此 时 通过 使 用 如 数据 库 读 写 分 离 或 者 Redis 这 种 缓存 来 文 撑 更 大 的 访问 
量 。 使 用 缓存 这 种 架构 会 遇 到 的 问题 ， 包 括 缓存 与 数据 库 数据 不 同步 造 
成 数据 不 一 致 〈 一 般 设 置 过 期 时 间 ) ， 或 者 Redis 不 可 用 时 直接 命中 数据 
库 导 致 数据 库 压 力 过 大 。 可 以 考虑 Redis 的 主 从 或 者 用 一 致 性 哈 希 算法 做 
分 片 的 Redis 集 群 。 使 用 缓存 这 种 架构 ， 要 求 应 用 对 数据 一 致 性 的 要 求 不 
征 很 高 。 比 如 ， 像 下 订单 这 种 要 落地 的 数据 ， 则 不 适合 用 Redis 存 储 ， 但 
征 ， 订 单 的 读 取 可 以 使 用 缓存 。 


20.2.2 OpenResty+Local Redis- MySQL 集 群 架构 


-一 一 一 一 一 一 一 一 一 一 一 后 端 Tomcat 集 群 


如 上 图 所 示 ，OpenResty 首 先 通 过 Lua 读 取 本 机 Redis 缓 存 ， 如 果 不 命 中 ， 
则 回 源 到 后 端 Tomcat 集 群 。 后 端 Tomcat 集 群 再 读 取 MySQL 数 据 库 。Redis 
都 是 安装 到 和 OpenResty 同 一 台 服 务 器 上 ，OpenResty 直 接 读 本 机 可 以 减 
2o PARIS 。Redis 通 过 主 从 方式 同步 数据 ，Redis 主 从 一 般 采 用 树 的 方式 
实现 。 


Redis1 


|omem | ECCE 
Redis1 Redis1 


如 上 图 所 示 ， 在 叶子 市 点 可 以 做 AOF 持 久 化 ， 保 证 在 主 Redis 不 可 用 时 能 
进行 恢复 。 如 对 Redis 很 依赖 ， 可 以 考虑 多 主 Redis 染 构 ， 而 不 是 单 主 ， 来 
防止 单 主 不 可 用 时 数据 的 不 一 致 和 击 罕 到 后 端 Tomcat 集 群 。 这 种 架构 的 
缺点 就 古 要 求 Redis 实 例 数据 量 较 小 ， 如 果 单机 内 存 不 足 ， 那 么 也 可 以 通 
过 如 尾 号 为 1 的 在 A 服 务 器 、 尾 号 为 2 的 在 B 服 务 器 这 种 方式 实现 。 缺 点 也 
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20.2.3 “OpenResty+Redis 集 群 +MySQL 集群 架构 
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如 上 图 所 示 ， 与 之 前 架构 不 同 的 是 ， 此 时 我 们 使 用 一 致 性 哈 希 算法 实现 
Redis 集 群 ， 而 不 是 读本 机 Redis， 保 证 其 中 一 台 不 可 用 时 ， 只 有 很 少 的 数 
据 会 丢失 ， 防 止 击 穿 到 数据 库 。Redis 集 群 分 片 可 以 使 用 Twemproxy。 如 
果 Tomcat 实 例 很 多 的 话 ， 就 要 考虑 Redis 和 MySQL 链 接 数 问题 ， 因 为 大 部 
分 RediyMySQL 客 户 端 都 是 通过 连接 池 实 现 ， 此 时 的 链接 数 会 成 为 瓶颈 。 
一 般 方 法 是 通过 中 间 件 来 减少 链接 数 。 


| Twemproxy | 


roor l 


| Redis | | Redis | | Redis | | Redis | 


如 上 图 所 示 ，Twemproxy 与 Redis 之 间 通 过 单 链接 交互 ， 并 通过 
oe 逻辑 。 这 样 我 们 可 以 水 平 扩 展 更 多 的 Twemproxy 来 增 
[链接 数 。 


此 时 的 问题 就 是 Twemproxy 实 例 众 多 ， 应 用 维护 、 配 置 困难 ， 需 要 在 这 之 
上 做 负载 均衡 ， 比 如 ， 通 过 LVS/HaProxy 实 现 VIP (虚拟 IP) ， 可 以 做 到 
J ` 故障 上 自动 转 移 。 还 可 以 通过 实现 内 网 DNS 来 做 其 负载 
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如 上 图 所 示 ， 本 文 没有 涉及 Nginx 之 上 是 如 何 架 构 的 ，Nginx、Redis、 
MySQL 等 的 负载 均衡 、 资 源 的 CDN 化 不 是 本 章 关 注 的 重点 ， 有 兴趣 请 查 
阅 相 关 资 料 。 

20.3 ”实现 


接 下 来 ， 我 们 来 搭建 一 下 第 四 种 架构 ， 如 下 图 所 示 。 


炎 ， 严 即 得 360 元 1 年 好 荚 坞 影视 资源 服务 费 | Fees ， 


假设 京东 有 10 亿 件 商 品 ， 那 么 广告 词 极限 情况 是 10 亿 个 ， 所 以 在 设计 时 
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. 是 K-V 还 是 关系 ， 是 否 需 要 批量 获取 ， 是 否 需 要 按照 规则 查询 。 

而 对 于 本 例 ， 广 告 词 更 新 量 不 会 很 大 ， 每 分 钟 可 能 在 儿 万 个 左右 。 而 且 
是 K-V 的 ， 其 实 适合 使 用 关系 存储 。 因 为 广告 词 是 商家 在 维护 ， 因 此 后 台 
查询 需要 知道 这 些 商 品 是 哪个 商家 的 。 而 前 台 是 不 关心 商家 的 ， 是 KV 在 
储 ， 所 以 前 台 显 示 可 以 放 进 如 Redis 中 ， 即 存在 两 种 设计 。 

.所 有 数据 存储 到 MySQL ， 然 后 热点 数据 加 载 到 Redis 。 

` 关系 存储 到 MySQL， 而 数据 存储 到 如 SSDB 这 种 持久 化 KV 存储 中 。 
基本 数据 结构 包括 商品 ID、 广 告 词 、 所 属 商 家 、 开 始 时 间 、 结 束 时 间 、 


是 否 有 效 。 

20.3.1 “后台 逻辑 

. 商家 登录 后 人 台 。 

按照 商家 分 页 查询 商家 数据 ， 此 处 要 按照 商品 关键 词 或 两 品类 目 查 询 的 
话 ， 需 要 走 商 品系 统 的 搜索 子 系统 ， 如 通过 Solr 或 ElasticSearch 实 现 搜 索 
子 系统 。 

. 进行 广告 词 的 增删 改 查 。 


- 增删 改 时 可 以 直接 更 新 Redis 绥 存 或 者 只 删除 Redis 缓 存 (第 一 次 前 台 
询 时 写 入 缓存 ) c 


20.3.2 Bil & 37 3H 
1. 首 先 Nginx 通 过 Lua 查 询 Redis 缓 存 。 
2. 查 询 不 到 的 话 回 源 到 Tomcat，Tomcat 读 取 数 据 库 查 询 到 数据 ， 然 后 把 最 


新 的 数据 异步 写 入 Redis (一 般 设置 过 期 时 间 ， 如 5min) 。 此 处 设计 时 要 
考虑 Tomcat 读 取 MySQL 的 极限 值 是 多 少 ， 然 后 设计 降级 开关 ， 如 假设 每 


[ri 


— 少 回 源 达到 100， 则 直接 不 查询 MySQL 而 返回 空 的 广告 词 来 防止 TomcatY 
雪 朋 。 


为 了 简单 ， 我 们 不 进行 后 台 的 设计 实现 ， 只 做 前 端的 设计 实现 ， 此 时 数 
据 结构 我 们 简化 为 [商品 ID、 广 告 词 ]。 男 外 有 读者 可 能 看 到 ， 可 以 直接 把 
Tomcat 部 分 干掉 ， 通 过 Lua 直 接 读 取 MySQL 进 行 回 源 实现 。 为 了 完整 性 ， 
此 处 我 们 还 是 做 回 源 到 Tomcat 的 设计 ， 因 为 如 果 逻 辑 比 较 复 杂 的 话 会 有 
一 些 限 制 (比如 使 用 Java 特 有 协议 的 RPC) ， 还 是 通过 Java 去 实现 更 方便 


一 些 o 


20.3.3 ”项 目 搭建 


项 目 部 署 目录 结构 。 


/usr/chapter6 
redis 6660.conf 
redis 6661.conf 
nginx chapter6.conf 
nutcracker.yml 
nutcracker.init 
webapp 

WEB-INF 
lib 
classes 
web.xml 


20.3.4 Redis* Twemproxy Éi Ei 


根据 实际 情况 来 决定 Redis 大 小 ， 此 处 我 们 已 经 有 两 个 Redis 实 例 (6660 ` 
6661) ， 在 Twemproxy 上 通过 一 致 性 哈 硕 做 分 片 逻 辑 。 


1. 安 装 
请 参考 《 跟 我 学 OpenResty (Nginx+Lua) 开发 》 中 第 3 章 的 内 容 。 
2.Redis 配 置 redis 6660.conf 和 redis 6661.conf 


# 分 别 为 6660 6661 


port 6660 

# 进 程 ID 分 别 改 为 redis_6660.pid redis 6661.pid 

pidfile "/var/run/redis 6660.pid" 

# 设 置 内 存 大 小 ， 根 据 实际 情况 设置 ， 此 处 测试 仅 设置 20MB 
maxmemory 20mb 

# 内 存 不 足 时 ， 按 照 过 期 时 间 进 行 LRU 删 除 
maxmemory-policy volatile-lru 


#Redis 的 过 期 算法 不 是 精确 的 而 是 通过 采样 来 算 的 ， 黑 认 采 样 为 3 个， 此 
处 我 们 改 成 10 


maxmemory-samples 10 


# 不 进行 RDB 持 久 化 


Ww 


save 
# 不 进行 AOF 持 久 化 
appendonly no 


将 如 上 配置 放 到 redis 6660.conf 和 redis 6661.conf 配 置 文 件 最 后 即 可 ， 后 
边 的 配置 会 履 盖 前 边 的 。 


3.Twemproxy 配 置 nutcracker.yml 


serverl: 
listen: 127.0.0.1:1111 
hash: fnvla 64 
distribution: ketama 
redis: true 
timeout: 1000 
servers: 
- 127.0.0.1:6660:1 serverl 
- 127.0.0.1:6661:1 server2 


复 制 nutcrackerinit 到 /usr/chapte6 F , 并 修改 配置 文件 
为 /usr/chapter6/nutcracker.yml ° 


4. 启 动 


nohup /usr/servers/redis-2.8.19/redis-server /usr/chapter6/redis 6660.conf & 
nohup /usr/servers/redis-2.8.19/redis-server /usr/chapter6/redis 6661.conf & 
/usr/chapter6/nutcracker.init start 


ps -aux | grep -e redis -e nutcracker 


20.3.5 MySQL+Atlas 配 置 


Atas 类 似 于 Twemproxy ， 是 Qihoo 360 基 于 MySQL Proxy 开 发 的 一 个 
MySQL 中 间 件 ， 据 称 每 天 承载 读 写 请 求 数 达 几 十 亿 ， 可 以 实现 分 库 

(sharding 版 本 ) 、 分 表 、 读 写 分 离 、 数 据 库 连 接 池 等 功能 ， 缺 点 是 没有 
实现 跨 库 分 表 〈 分 库 ) 功能 ， 需 要 在 客户 端 使 用 分 库 逻 辑 。 另 一 个 选择 
是 使 用 如 阿里 的 TDDL， 它 是 在 客户 端 实现 分 库 的 。 到 底 选 择 是 在 客户 端 
还 是 在 中 间 件 根据 实际 情况 来 选择 。 


此 处 我 们 不 做 MySQL 的 主 从 复制 ( 读 写 分 离 ) ， 只 做 分 库 分 表 实 现 。 
1.MySQL 初 始 化 
为 了 测试 我 们 此 处 分 两 个 表 (N=0/1) ° 
CREATE DATABASE chapter6 DEFAULT CHARACTER SET utf8; 
use chapter6; 
CREATE TABLE chapter6.ad N( 
sku id BIGINT, 


content VARCHAR(4000) 
) ENGINE-InnoDB DEFAULT CHARSET-utf8; 


2.Atlas Z3 


cd /usr/servers/ 
wget https://github.com/Qihoo360/Atlas/archive/2.2.1.tar.gz -0 Atlas -2.2. 
l.tar .gz 

tar -gyf Atlas-2.2.1.tar.gz 

cd Atlas-2.2.1/ 

#Atlas 依赖 mysql_config， 如 果 没 有 ， 则 可 以 通过 如 下 方式 安装 

apt-get install libmysqlclient-dev 

#2248 Lua 依赖 

wget http://www.lua.org/ftp/lua-5.1.5.tar.gz 

tar -xvi lua-5.1.5.tar.gz 

cd lua-5.1.5/ 

make linux && make install 

#248 glib 依赖 

apt-get install libglib2.0-dev 
安装 libevent 依赖 

apt-get install libevent 

# 安 装 flex 依赖 
apt-get install flex 

# 安 装 jemalloc 依赖 

apt- ANS install libjemalloc-dev 
# 安 装 OpenSSL 依赖 

apt-get install openssl 

apt-get install libssl-dev 
apt-get install 1libss10.9.8 


./configure --with-mysql=/usr/bin/mysql config 
./bootstrap.sh 
make && make install 


3.Atlasfi E 


vim /usr/local/mysql-proxy/conf/chapter6.cnf 
[mysql-proxy | 

#Atlas 代 理 的 主 库 ， 多 个 之 间 逗 号 分 隔 
proxy-backend-addresses = 127.0.0.1:3306 


COPINES 多 个 之 间 喜 号 分 隔 ， 格 式 ip:port@weight， 权 重 默 认 
为 1 


#proxy-read-only-backend-addresses = 127.0.0.1:3306,127.0.0.1:3306 

# 用 户 名 /密码 ， 密 码 使 用 /usr/servers/Atlas-2.2.1/script/encrypt 12345601% 
pwds = root:/iZxz+0GRoA= 

# 后 闻 进 程 运行 

daemon = true 

# 开 启 monitor 进 程 ， 当 worker 进 程 挂 了 自动 重启 

keepalive = true 

# 工 作 线 程 数 ， 对 Atlas 的 性 能 有 很 大 影响 ， 可 根据 情况 适当 设置 
event-threads = 64 


# 日 志 级 别 


log-level = message 


# 日 志 存 放 的 路 径 


log-path = /usr/chapter6/ 

# 实 例 名 称 ， 用 于 同一 台 机 右上 多 个 Atlas 实 例 间 的 区 分 
instance = test 

# 监 听 的 记 和 port 

proxy-address = 0.0.0.0:1112 

# 监 听 的 管理 接口 的 p 和 port 

admin-address = 0.0.0.0:1113 

# 管 理 接口 的 用 户 名 


admin-username = admin 


# 管 理 接 口 的 密码 

admin-password = 123456 

HIRIZ EE 

tables = chapter6.ad.sku_id.2 

HER FATE 

charset = utf8 

因为 本 例 没 有 做 读 写 分 离 ， 所 以 读 库 proxy-read-only-backend-addresses 没 
有 了 配置。 分 表 逻 辑 为 :， 数据 库 名 . 表 名 .分 表 键 . 表 的 个 数 ， 分 表 的 表 名 格式 
是 table_N，N 从 0 开始 。 

4.Atlas 启 动 /重启 /停止 


/usr/local/mysql-proxy/bin/mysql-proxyd chapter6 start 


/usr/local/mysgl-proxy/bin/mysgl-proxyd chapter6 restart 
/usr/local/mysql-proxy/bin/mysql-proxyd chapter6 stop 


如 上 命令 会 自动 到 /usr/local/mysql-proxy/conf 目 录 下 查找 chapter6.cnf 配 置 
文件 。 


5.Atlas 管 理 
通过 如 下 命令 进入 管理 接口 。 
mysql -h127.0.0.1 -P1113 -uadmin -p123456 


通过 执行 SELECT * FROM help 查 看 帮助 。 还 可 以 通过 一 
妖 的 动态 添加 / 移 除 。 


6.Atlas 客 户 端 
通过 如 下 命令 进入 客户 端 接 口 。 


mysql -h127.0.0.1 -P1112  -uroot -p123456 
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use chapter6; 

insert into ad values(1 ' 测 试 1); 
insert into ad values(2，' 测 试 27; 
insert into ad values(3 测试 3); 
select * from ad where sku id-1; 


select * from ad where sku_id=2; 


# 通 过 如 下 SQL 可 以 看 到 实际 的 分 表 结 


select * from ad 0; 

select * from ad 1; 

此 时 无 法 执行 select * from ad, a XE f Hj 4 “select * from ad where 
sku_id=1* 这 种 SQL 进行 查询 。 即 需要 带 上 sku id 是 必须 是 相等 比较 。 如 果 
是 范围 或 模糊 查询 ， 那 么 是 不 可 以 的 。 如 采 想 全 部 查询 ， 则 只 能 过 历 所 
有 表 进 行 查 询 ， 即 在 客户 端 做 查询 -聚合 。 


此 处 实际 的 分 表 逻 辑 是 按照 商家 进行 分 表 ， 而 不 是 按照 商品 编号 ， 因 为 
我 们 后 台 碍 询 时 是 按照 商家 维度 ， 此 处 是 为 了 测试 才 使 用 商品 编号 的 。 


至 此 基本 的 Atlas 就 介绍 完了 ， 更 多 内 容 请 参考 如 下 资料 。 


MySQL 主 从 复制 : http://369369.blog.51cto.com/319630/790921/ 


MySQL 中 间 件 介绍 : http://www.guokr.com/blog/475765/ 


Atlasfi FH: http://www.0550go.com/database/mysql/mysql-atlas.html 


Atlas X Ti 
https://github.com/Qihoo360/Atlas/blob/master/README_ZH.md 


20.3.6 Java* Tomcat Z3 
1.J ava 安 装 


cd /usr/servers/ 


# 首 先 到 如 下 网 站 下 载 JDK 


#http://www.oracle.com/technetwork/cn/java/javase/downloads/jdk7-downl 
oads-1880260.html 


# 本 文 下 载 的 是 jdk-7u75-linux-x64.tar.gz ° 

tar -xvf jdk-7u75-linux-x64.tar.gz 

vim ~/.bashre 

在 文件 最 后 添加 如 下 环境 变量 。 

export JAVA, HOME-/usr/servers/jdk1.7.0. 75/ 

export PATH=$JAVA_HOME/bin:$JAVA_HOME/jre/bin:$PATH 


export 
CLASSPATH=$CLASSPATH:.:$JAVA_HOME/lib:$JAVA_HOME/jre/lib 


# 使 环境 变量 生效 
source ~/.bashrc 


2.Tomcat 安 装 


cd /usr/servers/ 

wget 
http://ftp.cuhk.edu.hk/pub/packages/apache.org/tomcat/tomcat-7/v7.0.59/bi 
n/apache-tomcat-7.0.59.tar.gz 

tar -xvf apache-tomcat-7.0.59.tar.gz 

cd apache-tomcat-7.0.59/ 

# 局 动 

/usr/servers/apache-tomcat-7.0.59/bin/startup.sh 

Hub 

/usr/servers/apache-tomcat-7.0.59/bin/shutdown.sh 

# 删 除 Tomcat 默认 的 webapp 

rm -r apache-tomcat-7.0.59/webapps/* 

HA Catalina 目录 发 布 web 应 用 

cd apache-tomcat-7.0.59/conf/Catalina/localhost/ 

vim ROOT.xml 


3.ROOT.xml 

<!-- 访问 路 径 是 根 ，Web 应 用 所 属 目 孙 为 /asrchapter6/webapp --> 
«Context path="" docBase="/usr/chapter6/webapp"></Context> 

# 创 建 一 个 静态 文件 随便 添加 点 内 容 

vim /usr/chapter6/webapp/index.html 

HAD 

/usr/servers/apache-tomcat-7.0.59/bin/startup.sh 

访问 http://192.168.1.2:8080/index.html， 如 能 处 理 内 容 说 明 配 置 成 功 。 
# 变 更 目 孙 结构 

cd /usr/servers/ 

mv apache-tomcat-7.0.59 tomcat-server1 

# 此 处 我 们 创建 两 个 Tomcat 实 例 


cp -r tomcat-server1 tomcat-server2 


vim tomcat-server2/conf/server.xml 


# 如 下 端口 进行 变更 

8080--->8090 

8005--->8006 

局 动 两 个 Tomcat ° 

/usr/servers/tomcat-server1/bin/startup.sh 
/usr/servers/tomcat-server2/bin/startup.sh 

分 别 访问 如 下 两 个 地 址 ， 如 果 能 正常 访问 ， 则 说 明 配置 正常 。 
http://192.168.1.2:8080/index.html 

http://192.168.1.2:8090/index.html 

如 上 步骤 使 我 们 在 一 个 服务 右上 能 局 动 两 个 Tomcat 实 例 ， 这 样 的 好 处 是 


我 们 可 以 做 本 机 的 Tomcat 负 载 均衡 ， 假 设 一 个 Tomcat 重 启 时 另 一 个 是 可 
以 工作 的 ， 从 而 不 至 于 不 给 用 户 返 回 啊 应 。 


20.3.7 ”Java+Tomcat 逻 辑 开发 

1. 搭 建 项 目 

我 们 使 用 Maven 搭 建 Web 项 目 ，Maven 知 识 请 自行 学 习 。 
2. 项 目 依赖 


本 文 将 最 小 化 依赖 ， 即 仅 依 赖 我 们 需要 的 Servlet、MySQL 、Druid ^ 
Jedis ° 


«dependencies» 

«dependency» 
XgroupId»javax.servlet«/groupId» 
<artifactId>javax.servlet-api</artifactId> 
<version>3.0.1</version> 
<scope>provided</scope> 


</dependency> 

<dependency> 
«groupId»mysql«/groupId» 
«artifactId»mysql-connector-java«/artifactId» 
<version>5.1.27</version> 

</dependency> 

<dependency> 
<groupld>com.alibaba</groupId> 
<artifactId>druid</artifactId> 
<version>1.0.5</version> 

</dependency> 

<dependency> 
«groupId»redis.clients«/groupId» 
<artifactId>jedis</artifactId> 
<version>2.5.2</version> 

</dependency> 

</dependencies> 


3. 核 心 代码 


"Rit com.github.zhangkaitao.chapter6.servlet. AdServletf V f ° 


public class AdServlet extends HttpServlet { 
@Override 
protected void doGet (HttpServletRequest req, HttpServletResponse resp) 
throws ServletException, IOException { 

String idStr = req.getParameter ("id"); 

Long id = Long.valueOf (idStr) ; 

//1. BEAL MySOL 获取 数据 

String content = null; 

try { 
content = queryDB (id); 

} catch (Exception e) { 
e.printStackTrace(); 
resp.setStatus( 

HttpServletResponse.SC INTERNAL SERVER ERROR); 
return; 
} 
if(content != null) { 
//2.1 如 果 获取 到 ， 则 异步 写 Redis 
asyncSetToRedis(idStr, content); 
//2.2 如 果 获 取 到 ， 则 把 响应 内 容 返 回 
resp.setCharacterEncoding ("UTF-8") ; 
resp.getWriter() .write (content); 
} else { 


//2.3 如 果 获 取 不 到 ， 则 返回 404 状态 码 
resp.setStatus(HttpServletResponse.SC NOT FOUND); 


private DruidDataSource datasource = null; 
private JedisPool jedisPool - null; 


datasource - new DruidDataSource(); 
datasource.setUrl( 
"jdbc:mysql1://127.0.0.1:1112/chapter6?useUnicode-true&c 
haracterEncoding-utf-8&autoReconnect-true"); 
datasource.setUsername ("root"); 
datasource.setPassword ("123456"); 
datasource.setMaxActive (100) ; 


GenericObjectPoolConfig poolConfig = new GenericObjectPoolConfig(); 
poolConfig.setMaxTotal (100); 
jedisPool = new JedisPool(poolConfig, "127.0.0.1", 1111); 


private String queryDB(Long id) throws Exception { 
Connection conn = null; 
try { 
conn = datasource.getConnection(); 
String sql - "select content from ad where sku id - ?"; 
PreparedStatement psst - conn.prepareStatement (sql); 
psst.setLong(1, id); 
ResultSet rs - psst.executeQuery(); 
String content = null; 
if(rs.next()) { 
content = rs.getString("content"); 
} 
rs.close(); 
psst.close(); 
return content; 
} catch (Exception e) { 
throw e; 
} finally { 
if(conn != null) { 
conn.close(); 


private ExecutorService executorService = Executors.newFixedThreadPool (10); 
private void asyncSetToRedis(final String id, finalString content) { 
executorService.submit(new Runnable() { 
QOverride 
public void run() { 
Jedis jedis = null; 
try ( 
jedis = jedisPool.getResource(); 
jedis.setex(id, 5 * 60, content) ; //5 分 钟 
) catch (Exception e) { 
e.printStackTrace(); 
jedisPool.returnBrokenResource(jedis); 
) finally ( 
jedisPool.returnResource(jedis); 


整个 逻辑 比较 简单 ,此 处 更 新 缓存 一 般 使 用 异步 方式 去 实现 , 这 样 不 会 阻塞 主线 程 。 
另外 ， 此 处 可 以 考虑 使 用 Servlet 异步 化 来 提示 吞吐 量 。 


4.web.xml 配 置 


<servlet> 
<servlet-name>adServlet</servlet-name> 


«servlet-class»com.github.zhangkaitao.chapter6.servlet.AdServlet«/servlet 
-class> 
</servlet> 
<servlet-mapping> 
<servlet-name>adServlet</servlet-name> 
<url-pattern>/ad</url-pattern> 
</servlet-mapping> 


5. 打 WAR 包 
cd D:\workspace\chapter6 


mvn clean package 


此 处 使 用 maven 命 令 打 包 。 比 如 ， n war， 然 后 将 其 上 传 
到 服务 器 的 /usr/chapter6/webapp 文 件 中 ， 然 后 通过 unzip chapter6.war 解 
bees 


6. 测 试 

启动 Tomcat 实 例 ， 分 别 访问 如 下 地 址 将 看 到 广告 内 容 。 
http://192.168.1.2:8080/ad?id=1 
http://192.168.1.2:8090/ad?id=1 

7.Nginx 配 置 


编辑 /usr/chapter6/nginx_chapter6.conf 配置 文件 。 


upstream backend { 
server 127.0.0.1:8080 max fails-5 fail timeout-10s weight=1 backup= 


false; 
server 127.0.0.1:8090 max fails-5 fail timeout-10s weight=1 backup= 
false; 
check interval-3000 rise-1 fal#2 timeout-5000 type-tcp default down 
false; 
keepalive 100; 
) 
server ( 


listen 80; 
server name  ; 


location ~ /backend/(.*) ( 
keepalive timeout 30s; 
keepalive requests 100; 


rewrite /backend(/.*) $1 break; 

# 之 后 该 服务 将 只 有 内 部 使 用 ，ngx .Location.capture 
proxy pass request headers off; 

#more clear input headers Accept-Encoding; 
proxy next upstream error timeout; 

proxy pass http://backend; 


upstream 配 
( http://nginx.org/cn/docs/http/ngx_http_upstream_module.html) 有 如 下 项 


"server: ”指定 上 游 到 的 服务 器 。 


weight: 权重 ， 权 重 可 以 确定 负载 均衡 的 比例 。 


fail timeout+max fails: 在 指定 时 间 内 失败 多 少 次 后 认为 服务 器 不 
可 用 ， 通 过 proxy_next_upstream 来 判断 是 否 失 败 。 


- check: ngx_http_upstream_check_module 模 块 ， 上 游 服务 器 的 健康 检 


f 


interval: 发 送 心 跳 包 的 时 间 间 隔 。 


rise: 连续 成 功 rise 次 数 则 认为 服务 器 局 动 。 


fall: 连续 失败 fall 次 ， 则 认为 服务 器 连接 失败 。 


timeout: 上 游 服务 器 请 求 超时 时 间 。 


type: 心跳 检测 类 型 (比如 此 处 使 用 TCP) 。 


更 多 配置 请 参考 https://github.com/yaoweibin/nginx_upstream_check_module 
Allhttp://tengine.taobao.org/document_cn/ http upstream check cn.html ° 


` keepalive: 用 来 支持 upstream server http keepalive 特 性 〈 需 要 上 游 服务 
器 支持 ， 比 如 Tomcat) 。 默 认 的 负载 均 衡 算法 是 round-robin， 还 可 以 根据 
IP、URL 等 通过 哈 希 算法 来 实现 负载 均衡 。 更 多 资料 请 参考 官方 文档 。 


tomcat keepalive 配 置 有 如 下 项 目 (http://tomcat.apache.org/tomcat-7.0- 
doc/config/ http.html) 。 


: maxKeepAliveRequests: 默认 为 100 ° 
` keepAliveTimeout: 默认 等 于 connectionTimeout， 默 认为 60 秒 。 


location proxy 配 置 有 如 ie 项 H 
(http://nginx.org/cn/docs/http/ngx http proxy module.html) ° 


rewrite: 将 当前 请 求 的 URL 重 写 ， 如 我 们 请 求 时 是 /backend/ad， 则 重 写 
后 是 /ad ° 


-proxy_pass: ”将 整个 请 求 转发 到 上 游 服 务 器 。 


. proxy_next_upstream: ”负载 均衡 参数 ， 用 来 认定 什么 情况 下 视 为 当前 
upstream server KI, BRIA BEAM EA © 


‘ proxy_pass_request_headers: 之 前 已 经 介绍 过 ， 有 两 个 用 途 ， 一 是 如 
上 游 服务 器 不 需要 请 求 头 ， 则 没 必 要 传输 请 求 头 ; 二 是 
ngx.location.capture 时 Hj ?€ BF IE gzip ÉL WH (也 可 以 使 用 


more_clear_input_headers 配 置 ) 。 


. keepalive: ”keepalive_timeout 为 keepalive 的 超时 设置 ，keepalive_requests 
为 长 连接 数量 。 此 处 的 keepalive (别人 访问 该 location 时 的 长 连接 ) 和 
upstream keepalive (Nginx 与 上 游 服 务 器 的 长 连接 ) 是 不 一 样 的 。 要 注 
意 ， 如 果 服 务 是 面向 客户 的 ， 而 且 是 单个 动态 内 容 ， 则 没 必要 使 用 长 连 


接 。 
编辑 /usr/servers/nginx/conf/nginx.conf 配 置 文件 。 


include /usr/chapter6/nginx_chapter6.conf; 


# 为 了 方便 测试 ， 注 释 掉 example.conf 
#include /usr/example/example.conf; 
重启 Nginx。 
/usr/servers/nginx/sbin/nginx -s reload 


访问 如 192.168.1.2/backend/ad?id=1 即 看 到 结果 。 可 以 停 掉 一 个 Tomcat， 可 
以 看 到 服务 还 是 正常 的 。 


在 vim /usr/chapter6/nginx_chapter6.conf 文 件 中 进行 配置 或 修改 。 


location ~ /backend/(.*) { 
internal; 
keepalive timeout 309; 
keepalive requests 1000; 
£X keep-alive 
proxy http version 1.1; 
proxy set header Connection ""; 


rewrite /backend(/.*) $1 break; 

proxy pass request headers off; 

#more clear input headers Accept-Encoding; 
proxy next upstream error timeout; 


proxy pass http://backend; 
} 


加 上 internal， 表 示 只 有 内 部 使 用 该 服务 。 


20.3.8 Nginx+Lua 逻 辑 开发 
1. 核 心 代码 

编辑 /usr/chapter6/ad.lua 代 码 。 

local redis = require("resty.redis") 

local cjson = require("cjson") 


local cjson encode = cjson.encode 


local ngx log = ngx.log 

local ngx ERR = ngx.ERR 

local ngx exit = ngx.exit 

local ngx print = ngx.print 

local ngx re match = ngx.re.match 
local ngx var 7 ngx.var 


local function close redis(red) 


if not red then 
return 
end 
-- 释 放 连 接 〈 连 接 池 实 现 ) 
local pool max idle time = 10000 -- 毫 秒 
local pool size = 100 -- 连 接 池 大 小 
local ok, err = red:set keepalive(pool max idle time, pool size) 


if not ok then 
ngx log(ngx ERR, "set redis keepalive error : ", err) 
end 
end 
local function read redis (id) 
local red = redis:new() 
red:set timeout (1000) 


local ip = "127.0.0.1" 
local port = 1111 
local ok, err = red:connect(ip, port) 
if not ok then 
ngx log(ngx ERR, "connect to redis error : ", err) 


return close redis (red) 
end 


local resp, err = red:get (id) 
if not resp then 
ngx log(ngx ERR, "get redis content error : ", err) 
return close redis (red) 
end 
-- 得 到 的 数据 为 空 处 理 
if resp == ngx.null then 
resp - nil 
end 
close redis (red) 


return resp 
end 


local function read http(id) 
local resp = ngx.location.capture ("/backend/ad", { 
method = ngx.HTTP GET, 
args = {id = id} 
}) 


if not resp then 


ngx log(ngx ERR, "request error :", err) 
return 
end 


if resp.status -- 200 then 
ngx log(ngx ERR, "request error, status :", resp.status) 
return 

end 


return resp.body 
end 


-- 获 取 id 
local id = ngx var.id 


-- 从 Redis 获取 
local content = read redis (id) 


--WIA Redis 没有 ， 则 回 源 到 Tomcat 

if not content then 
ngx log(ngx ERR, "redis not found content, back to http, id : ", id) 
content - read http(id) 

end 


-- 如 果 还 没有 ， 则 返回 404 


if not content then 


ngx log(ngx ERR, "http not found content, id : ", id) 
return ngx exit(404) 

end 

-- 输 出 内 容 


ngx.print("show ad(") 
ngx print(cjson encode((content = content])) 
ngx.print (™)"") 


将 可 能 经 常用 的 变量 做 成 局 部 变量 ， 如 local ngx_print = ngx.print。 使 用 
jsonp 方 式 输出 ， 此 处 可 以 将 请 求 URL 限 定 为 /ad/id 方 式 ， 这 样 的 好 处 是 可 
以 尽 可 能 早 地 识别 无 效 请 求 。 可 以 走 Nginx 绥 存 /CDN 绥 存 ， 缓 存 的 key 就 
是 URL， 而 不 带 任 何 参 数 ， 防 止 那些 在 URL 加 随机 参数 后 罕 透 缓存 。 
J 固定 的 回调 函数 show_ad0， 或 者 限定 几 个 固定 的 回调 来 减少 组 
子 N o 


在 vim /usr/chapter6/nginx_chapter6.conf 文 件 中 进行 配置 或 修改 。 


location ~ ^/ad/(\d+)$ { 

default type 'text/html'; 

charset utf-8; 

lua code cache on; 

set Sid $1; 

content by lua file /usr/chapter6/ad.lua; 
} 


2. 重 启 Nginx 


/usr/servers/nginx/sbin/nginx -s reload 


访问 如 http:/192.168.1.2/ad/1 即 可 得 到 结果 。 而 且 注 意 观 察 日 志 ， 第 一 次 
访问 时 不 命中 Redis， 回 源 到 Tomcat。 第 二 次 请 求 时 就 会 命中 Redis 了 。 


第 一 次 访问 时 ， 将 看 到 /usr/servers/nginx/logs/error.log 输 出 类 似 如 下 的 内 
容 ， 而 第 二 次 请 求 相同 的 URL 不 再 有 如 下 内 容 。 


redis not found content, back to http, id : 2 


至 此 整个 架构 就 介绍 完了 ， 此 处 可 以 直接 不 使 用 Tomcat， 而 是 Lua 直 连 
MySQL 做 回 源 处 理 。 另 外 ， 本 文 只 是 介绍 了 大 体 架 构 ， 还 有 更 多 业务 及 
运 维 上 的 细节 需要 在 实际 应 用 中 根据 自己 的 场景 进行 摸索 。 后 续 如 使 用 
LVSrtAProx L BOS > (EICON E BTR RRE WET 


本 文 节 选 自 笔者 的 开源 电子 书 《 跟 我 学 OpenResty (Nginx+Lua) 开发 》 
的 第 6 章 ， 相 关 基 础 知识 可 扫 二 维 码 进行 参考 。 


口 h 


21 使 用 OpenResty 开 发 商品 详情 页 


在 第 16 章 中 已 经 介绍 了 设计 商品 详情 页 的 整体 架构 和 要 点 ， 本 章 将 以 永 
东 商 品 详情 页 为 例 讲 解 如 何 开 发 商品 详情 页 。 东 东 商 品 详情 页 虽然 仅 是 
单个 页 面 ,但 是， 其 数据 聚合 源 古 非常 多 的 ， 除 了 一 些 实时 性 要 求 比较 
高 的 如 价格 、 库 存 、 服 务 支 持 等 通过 AJAX 异 步 加 载 之 外 ， 其 他 的 数据 都 
征 在 后 端 做 数据 聚合 ， 然 后 拼装 网 页 模板 。 


En 手机 通讯 > 手机 苹果 (Apple) 苹果 iFhone 6 | 
苹果 ( Apple ) iPhone 6 (A1586) 16GB 金色 移动 联通 电信 4G 手 机 对 比 
关注 iPhone6 jd.com 
【点 击 ` 电 信 防 费 ( 全 网 通 16G)"】4988 元 限量 1000 台 秒 完 即 止 ! 送 壳 烤 套 装 ， 价 值 1 
50 元 流量 包 ! 
京东 自 营 
京 东 fi: ¥5188.00 降价 通知 ) 9080 ; 
促销 信息 : 薄 1999 0 元 另 加 79.0 元 即 可 购买 热 销 商品 详情 >> 
服务 支持 : 
BIE (i524 0k iMRG 详情 > 
Bg sas Ies 
配 送 至 : | 北京 朝阳 区 三 环 以 内 v 有 货 ， 支 持 货 到 付款 | 免 运费 
手机 号 码 是 否 四 本 该 机 型 ? 
BRO ” 务 : 由 京东 发 代 并 提供 售后 服务 。23:00 前 完成 下 单 ， 预 计 明 日 (02 月 27 日 》 送 达 
立即 查询 
提示 : 因 部 分 区 域 号 段 运 营 商 存在 
人 开导 (12868 ROM) 差异 ， 本 查 词 结果 仅 作 参 考 
关于 手机 ,你 可 能 在 找 商品 介 绍 | | 规格 参数 | [包装 清单 商品 评价 (9080) [售后 保障 SP mon 
超 薄 7mm 以 下 ”支持 NFC 
屏幕 尺寸 : 47 英 十 ERREA: 800 万 像素 
5046 英 寸 。 直 全 约 机 Bi: 1334x750 MARGA: 1205F 
苹果 (IOS) 移动 4G 
联通 4G ”电信 4G — 移动 3G 
联通 3G 。 电信 3G 商品 名 称 : 苹果 iPhone 6 商品 编号 : 1217499 品牌 : 苹果 (Apple) 388i: 2014-10-09 22:29:09 
商品 毛重 : 400.009 商品 产地 : 中 国 大 陆 热点 : ETMT 支持 NFC 机 身 颜色 : 金色 
移动 2G 磋 通 2G 。 电信 2G 系统 : 苹果 (IOS) 购买 方式 : 非 合 约 机 
28 更 多 参数 >> 
同类 其 他 品牌 dp, 如 果 您 发 现 商品 信 息 不 准确 ， 欢 迎 纠 措 四 产品 特色 
联想 华为 B 
酷派 苹果 zg 产品 特色 Selling Point 
JK (MD. 诺基亚 中兴 
HTC TCL 索尼 . 
xu m iPhone 6 
tS Hu LG uw 
摩托 罗拉 dx 岂止 于 大 
in VA 


如 上 图 所 示 ， 商 品 页 主要 包括 商品 基本 信息 (基本 信息 、 图 片 列表 、 颜 
色 /尺码 关 系 、 扩 展 属性 、 规 格 参数 、 包 闭 清 单 、 售 后 保障 等 、 商 品 介 
绍 、 其 他 信息 【分 类 、 品 牌 、 店 铺 (第 三 方 卖家 ) 、 店 内 分 类 (第 三 方 
SER) 、 同 类 相关 品牌 ] 。 更 多 细节 此 处 就 不 再 详细 立 述 。 


整个 京东 有 数 亿 商品 ， 如 采 每 次 都 要 动态 获取 如 上 内 容 进 行 模板 拼装 ， 
那么 数据 来 源 之 多 将 使 性 能 无 法 满足 要 求 。 最 初 的 解决 方案 是 生成 静态 
页 ， 但 是 ， 静 态 页 的 最 大 问题 是 无 法 迅速 啊 应 页 面 需求 变更 ， 很 难 做 多 
版 本 线 上 对 比 测 试 。 如 上 两 个 因素 足以 制约 商品 页 的 多 样 化 发 展 ， 
此 ， 静 态 化 技术 不 是 很 好 的 方案 。 


通过 分 析 ， 数 据 主要 分 为 四 种 : 商品 页 基本 信息 、 商 品 介绍 (异步 加 
载 ) 、 其 他 信息 (oR > mE > SS) 、 其 他 需要 实时 展示 的 数据 

(Uri > RES) 。 而 其 他 信息 如 分 类 、 品 牌 、 店 铺 是 非常 少 的 ， 完 全 
可 以 放 到 一 个 占用 内 存 很 小 的 Redis 中 存储 。 而 商品 基本 信息 可 以 借鉴 静 
仿 化 技术 将 数据 做 案 合 存储 ， 数 据 十 原子 的 ， 而 模板 古 随 时 可 变 的 ， 这 
样 的 好 处 是 吸收 了 静态 页 宫 合 的 优点 ， 弥 补 了 静态 页 的 多 版 本 中 操 。 男 
外 一 个 非常 严重 的 问题 就 古 闫 重 依 赖 相 关系 统 ， 如 末 它 们 无 法 正常 运行 
或 响应 慢 ， 则 商品 页 束 会 直接 受到 影响 。 商 品 介 绍 也 通过 AJAX 技 术 惰 性 
me (因为 是 第 二 屏 ， 只 有 当 用 户 滚动 鼠标 到 该 屏 时 才 显 示 ) 。 而 实时 
展示 数据 通过 AJAX 技 术 做 异步 加 载 。 因此 可 以 做 如 下 设计 。 


1. 接 收 商 品 变更 消息 ， 做 商品 基本 信息 的 聚合 ， 即 从 多 个 数据 源 获取 商品 
相关 信息 ， 如 图 片 列表 、 颜 色 尺 码 、 规 格 参数 、 扩 展 属性 等 ， 聚 合 为 一 
个 大 的 JSON 数 据 做 成 数据 闭环 ， 以 key-value 存 储 。 因 为 是 闭环 ， 所 以 即 
商品 页 还 能 继续 服务 ， 对 商品 页 不 会 造成 任何 
影响 。 

2. 接 收 商 品 介 绍 变更 消息 ， 存 储 商 品 介 
3. 介 绍 其 他 信息 变更 消息 ， 存 储 其 他 信息 。 


整个 架构 如 下 图 所 示 。 


is 
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基本 信息 
SSDB 集 群 
一 全 分 类 聚合 到 r 

DMQ 变 更 消息 | ”数据 聚合 各 个 集 桩 商品 介绍 
上 Twemprox Twemprox 
Worker | sided SSDB 集 群 

习 RpC 吝 用 N 个 系统 获取 数据 其 他 信息 

Redis 
BRPC 调 用 N 个 系统 获取 数 # 
其 他 服务 | 
异步 通知 数据 变更 TRU 
动态 服务 


MQ 可 以 使 用 如 Apache ActiveMQ ° 
Worker 动 态 服务 可 以 通过 如 Java 技 术 实 现 。 
RPC 可 以 选择 Alibaba Dubbo ° 


KV 持久 化 存储 可 以 选择 SSDB (如 果 使 用 SSD 盘 ， 则 可 以 选择 
SSDB+RocksDB 引 擎 ) 或 者 ARDB (LMDB 引 警 版 ) 。 


缓存 使 用 Redis。 


SSDB/Redis 4} Fr fii H Twemproxy ， 这 样 不 管 使 用 Java 还 是 OpenResty 
(Nginx*Lua) ， 它 们 都 不 关心 分 片 逻 辑 。 


前 端 模 板 拼 装 使 用 OpenResty。 


数据 集群 数据 存储 的 机 器 可 以 采用 RAID 技 术 或 者 主 从 模式 防止 单 点 故 
障 。 因 数据 变更 不 频繁 ， 可 以 考虑 用 SSD 奉 代 HDD 。 


21.2 ”核心 流程 
1. 首 先 ， 监 听 商 品 数据 变更 消息 。 


2. 接 收 到 消息 后 ， 数 据 聚 合 Wworker 通 过 RPC 调 用 相关 系统 获取 所 有 要 展示 
的 数据 ， 此 处 获取 数据 的 来 源 可 能 非常 多 ， 而 且 啊 应 速度 完全 受制 于 这 
些 系统 ， 可 能 耗 时 几 百 毫秒 甚至 1 秒 以 上 的 时 间 。 


3. 将 数据 聚合 为 JSON 趾 存储 到 相关 数据 集群 。 


4. 前 端 Nginx 通 过 Lua 获 取 相 关 集 群 的 数据 进行 展示 。 商 品 页 需要 获取 基本 
信息 和 其 他 信息 进行 模板 拼装 ， 即 拼装 模板 仅 需 要 两 次 调用 (另外 ， 
为 其 他 信息 数据 量 少 且 对 一 致 性 要 求 不 高 ， 因 此 ， 完 全 可 以 缓存 到 Nginx 
本 地 全 局 内 存 ， 这 样 可 以 减少 远程 调用 、 提 高 性 能 ) 。 当 页 面 滚动 到 商 
品 介绍 页 面 时 ， 有 异步 调用 商品 介绍 服务 获取 数据 。 


5. 如 末 从 聚合 的 SSDB 集 群 /Redis 中 获取 不 到 相关 数据 ， 则 回 产 到 动态 服 
务 ， 通 过 RPC 调 用 相关 系统 获取 所 有 要 展示 的 数据 返回 (此 处 可 以 做 限 
流 处 理 ， 因 为 《如果 同一 时 间 请 求 过 多 ， 那 么 可 能 导致 服务 雪 般 ， 所 以 
需要 采取 保护 措施 ) ， 此 处 的 逻辑 和 数据 聚合 Worker 完 全 一 样 。 然 后 发 


送 MQ 通 知 数据 变更 ， 这 样 下 次 访问 时 就 可 以 从 聚合 的 SSDB 集 群 /Redis 中 
获取 数据 了 。 
基本 流程 如 上 所 述 ， 主 要 分 为 Worker、 动 态 服务 、 数 据 存储 和 前 端 展 


示 。 因 为 系统 非常 复杂 ， 只 介绍 动态 服务 和 前 端 展 示 、 数 据 存储 架构 。 
Worker 部 分 不 做 实现 。 


213 ”项 目 搭建 


Mi E EAR: H RH 。 


/usr/chapter?7 
ssdb basic 7770.conf 
ssdb basic 7771.conf 
ssdb basic 7772.conf 
ssdb basic 7773.conf 
ssdb desc 8880.conf 
ssdb desc 8881.conf 
ssdb desc 8882.conf 
ssdb desc 8883.conf 
redis other 6660.conf 
redis other 6661.conf 


nutcracker.yml 
nutcracker.init 
item.html 
header.html 
footer.html 
item.lua 
desc.lua 
lualib 

item.lua 

item 

common. lua 
webapp 
WEB-INF 

Lib 

classes 
web.xml 


为 了 演示 需要 ， 将 各 种 配置 文件 都 打包 到 一 个 目录 下 ， 包 括 SSDB、 
Redis、OpenResty、OpenResty 项 目 、Web 项 目 。 


21.4 数据 存储 实现 


其 他 信息 Redis (E) 


其 他 信息 Redis (从 ) 其 他 信息 Redis (从 ) 
6661 6662 
^ ` 


pe a a i i iaj EG ee ee ee ee ein es eae ee ee 


如 上 图 所 示 ， 整 体 架 构 为 主 从 模式 ， 写 数据 到 主 集群 ， 读 数据 从 从 集群 
读 取 数据 ， 这 样 当 一 个 集群 不 足以 支撑 流量 时 可 以 使 用 更 多 的 集群 来 支 
撑 更 多 的 访问 量 。 和 集群 分 片 使 用 Twemproxy 实 现 。 


21.4.1 ”商品 基本 信息 SSDB 集 群 配置 


编辑 /usrchapter7/ssdb_basic_7770.conf 配 置 文件 。 


work dir = /usr/data/ssdb 7770 
pidfile - /usr/data/ssdb 7770.pid 


server: 
ip: 0.0.0.0 
port: 7770 
allow: 127.0.0.1 
allow: 192.168 


replication: 
binlog: yes 
sync speed: -1 
slaveof: 


logger: 
level: error 
output: /usr/data/ssdb 7770.10g 
rotate: 
size: 1000000000 


leveldb: 
cache size: 500 
block sizex 32 
write buffer size: 64 
compaction speed: 1000 
compression: yes 


编辑 /usrchapter7/ssdb_basic_7771.conf 配 置 文件 。 


work dir = /usr/data/ssdb 7771 
pidfile - /usr/data/ssdb 7771.pid 


server: 
Te 020:ü0.:0 
port: 7771 
allows JX2T.0.0.1 
allow: 192.168 


replication: 
binlog: yes 
sync speed: -1 
slaveof: 
logger: 
level: error 
output: /usr/data/ssdb 7771.10g 
rotate: 
size: 1000000000 


leveldb: 
cache size: 500 
Hlonkb size: 32 
write buffer size: 64 
compaction speed: 1000 
compression: yes 


编辑 /usrchapter7/ssdb_basic_7772.conf 配 置 文件 。 


work dir - /usr/data/ssdb 7772 


pidfile = /usr/data/ssdb 7772.pid 


server: 
Ypi 0.0.0.0 
pott: 7/72 
allows 1274.0.0,.1 
allow: 192.168 


replication: 
binlog: yes 
sync speed: -1 


slaveof: 
type: sync 
rp: 127.050; 
port: 7770 


logger: 
level: error 
output: /usr/data/ssdb 7772.log 
rotate: 
size: 1000000000 


leveldb: 
cache Size 500 
block Sizes 32 
write buffer size: 54 
compaction speed: 1000 
compression: yes 


编辑 /usrchapter7/ssdb_basic_7773.conf 配 置 文件 。 


work dir = /usr/data/ssdb 7773 
pidfile - /usr/data/ssdb 7773.pid 


server: 
ip: 0.0.0.0 
pores, TITS 
allow: 127.0.0.1 
allow: 192.168 


replication: 
binlog: yes 
sync speed: -1 
slaveof: 
type: sync 
rp? 1275:0.0.1 


port: 7771 


logger: 
level: error 
output: /usr/data/ssdb 7773.10g 
rotate: 
size: 1000000000 


leveldb: 
cache size: 500 
block size: 32 
write buffer size: 64 
compaction speed: 1000 
compression: yes 


配置 文件 使 用 Tab 而 不 是 用 空格 做 缩 排 ， (复制 到 配置 文件 后 请 把 空格 奉 
换 为 Tab) 。 主 从 关系 : 7770 (GE) 27772 (M) , 7771 (XE) 27773 
CA) 。 配 置 文件 如 何 配 置 请 参考 https://github.com/ideawu/ssdb- 


docs/blob/master/src/zh cn/config.md ° 
创建 工作 目 隶 。 
mkdir -p /usr/data/ssdb_7770 


mkdir -p /usr/data/ssdb_7771 


mkdir -p /usr/data/ssdb 7772 
mkdir -p /usr/data/ssdb 7773 
局 动 。 


nohup /usr/servers/ssdb-1.8.0/ssdb-server /usr/chapter7/ 
ssdb basic 7770.conf & 


nohup /usr/servers/ssdb-1.8.0/ssdb-server /usr/chapter7/ 
ssdb basic 7771.conf & 


nohup /usr/servers/ssdb-1.8.0/ssdb-server 
/usr/chapter7/ssdb basic 7772.conf & 


nohup /usr/servers/ssdb-1.8.0/ssdb-server /usr/chapter7/ 
ssdb basic 7773.conf & 


通过 ps -aux | grep ssdb 命 令 查 看 是 否 启动 ，tail -f nohup.out 查 看 错误 信 


o 
JON 


21.4.2 ”商品 介绍 SSDB 集 群 配置 


编辑 /usr/chapter7/ssdb_desc_8880.conf 配置 文件 。 


work dir = /usr/data/ssdb 8880 
pidfile = /usr/data/ssdb8880.pid 


server: 
ip: 0.0.0.0 
port: 8880 


allow: 127.0.0.1 
allow: 192.168 


replication: 
binlog: yes 
sync speed: -1 
slaveof: 
logger: 
level: error 
output: /usr/data/ssdb 8880.10g 
rotate: 
size: 1000000000 


leveldb: 
cache size: 500 
block size: 32 
write buffer size? 64 
compaction speed: 1000 
compression: yes 


2m R/usr/chapter7/ssdb desc 8881.conf 配置 文件 。 


work dir = /usr/data/ssdb 8881 
pidfile = /usr/data/ssdb8881.pid 


server: 
ip: 0.0.0.0 
port: 8881 
allow: 127.0.0.1 
allow: 192.168 


logger: 
level: error 
output: /usr/data/ssdb 8881.10g 
rotate’: 
size: 1000000000 


leveldb: 
cache size: 500 
blodk Size: 32 
write buffer size; 64 
compaction speed: 1000 
compression: yes 


编辑 /usr/chapter7/ssdb_desc_8882.conf 配置 文件 。 


work dir = /usr/data/ssdb 8882 
pidfile = /usr/data/ssdb 8882.pid 


server: 
ip: 0.0.0.0 
port: 8882 
allow: 127.:040.1 
allow: 192.168 


replication: 

binlog: yes 
sync speed: -1 

slaveof: 
replication: 

binlog: yes 
sync speed: -1 


Slaveof: 
type: sync 
ip: 127.0.0&.1 
port: 8880 
logger: 


level: error 
output: /usr/data/ssdb 8882.10g 
rotate: 

size: 1000000000 


leveldb: 
cache size: 500 
block size? 32 
write buffer size; 64 
compaction speed: 1000 
compression: yes 


7m R/usr/chapter7/ssdb desc 8883.conf 配置 文件 。 


work dir = /usr/data/ssdb 8883 
pidfile - /usr/data/ssdb 8883.pid 


server: 
ip: 0.0.0.0 
port: 8883 
allow: 127.0.0.1 
allow: 192.168 


replication: 
binlog: yes 
sync speed: -1 


slaveof: 
type: sync 
ipi 127.0..0.1 
port: 8881 
logger: 


level: error 
output: /usr/data/ssdb 8883.10g 
rotate: 

Size: 1000000000 


leveldb: 
cache size: 500 
block size: 32 
write buffer size: 64 


compaction speed: 1000 
compression: yes 


配置 文件 使 用 Tab 而 不 是 用 空格 做 缩 排 (复制 到 配置 文件 后 请 把 空格 蔡 换 
JjTab) 。 主 从 关系 : 7770 (E) 27772 (MO , 7771 (E) -7773 
CA) 。 配 置 文件 如 何 配 置 请 参考 https://github.com/ideawu/ssdb- 


docs/blob/master/src/zh cn/config.md ° 
创建 工作 目录 。 

mkdir -p /usr/data/ssdb_888{0,1,2,3} 
局 动 。 


nohup /usr/servers/ssdb-1.8.0/ssdb-server /usr/chapter7/ 
ssdb desc 8880.conf & 


nohup /usr/servers/ssdb-1.8.0/ssdb-server /usr/chapter7/ 
ssdb desc 8881.conf & 


nohup /usr/servers/ssdb-1.8.0/ssdb-server  /usr/chapter7/ssdb desc 8882.conf 
& 


nohup /usr/servers/ssdb-1.8.0/ssdb-server  /usr/chapter7/ssdb desc 8883.conf 
& 


通过 ps -aux | grep ssdb 命 令 查 看 是 否 启动 ，tail -f nohup.out 查 看 错误 信 
E o 


JON 


21.4.3 ”其 他 信息 Redis 配 置 


编辑 /usr/chapter7/redis_6660.conf 配置 文件 。 


port 6660 

pidfile "/var/run/redis 6660.pid" 

# 设 置 内 存 大 小 ， 根 据 实际 情况 设置 ， 此 处 测试 仅 设置 20MB 
maxmemory 20mb 

# 内 存 不 足 时 ， 所 有 KEY 按 照 LRU 算 法 删除 
maxmemory-policy allkeys-lru 


#Redis 的 过 期 算法 不 是 精确 的 ， 而 是 通过 采样 来 算 的 ， 默 认 采 样 为 3 个 ， 
此 处 我 们 改 成 10 


maxmemory-samples 10 


# 不 进行 RDB 持 久 化 


Ww 


Save 


# 不 进行 AOF 持 久 化 

appendonly no 

编辑 /usr/chapter7/redis_6661.conf 配置 文件 。 

port 6661 

pidfile "/var/run/redis 6661.pid" 

# 设 置 内 存 大 小 ， 根 据 实 际 情况 设置 ， 此 处 测试 仅 设 置 20MB 
maxmemory 20mb 

# 内 存 不 足 时 ， 所 有 key 按 照 LRU 算 法 进行 删除 
maxmemory-policy allkeys-lru 


#Redis 的 过 期 算法 不 是 精确 的 ， 而 是 通过 采样 来 算 的 ， 默 认 采 样 为 3 个 ， 
此 处 我 们 改 成 10 


maxmemory-samples 10 


# 不 进行 RDB 持 久 化 


Ww 


save 
# 不 进行 AOF 持 久 化 

appendonly no 

# 主 从 

slaveof 127.0.0.1 6660 

编辑 /usr/chapter7/redis_6662.conf 配置 文件 。 
port 6662 


pidfile "/var/run/redis 6662.pid" 


# 设 置 内 存 大 小 ， 根 据 实际 情况 设置 ， 此 处 测试 仅 设 置 20MB 
maxmemory 20mb 

# 内 存 不 足 时 ， 所 有 key 按 照 LRU 算 法 进行 删除 
maxmemory-policy allkeys-lru 


#Redis 的 过 期 算法 不 是 精确 的 ， 而 是 通过 采样 来 算 的 ， 默 认 采 样 为 3 个 ， 
此 处 我 们 改 成 10 


maxmemory-samples 10 


# 不 进行 RDB 持 久 化 


Ww 


save 
# 不 进行 AOF 持 久 化 

appendonly no 

# 主 从 

slaveof 127.0.0.1 6660 

如 上 配置 放 到 配置 文件 最 末尾 即 可 。 此 处 内 存 不 足 时 的 驱逐 算法 为 所 有 
启动 。 


nohup /usr/servers/redis-2.8.19/redis-server /usr/chapter7/redis 6660.conf & 
nohup /usr/servers/redis-2.8.19/redis-server /usr/chapter7/redis 6661.conf & 


nohup /usr/servers/redis-2.8.19/redis-server /usr/chapter7/redis 6662.conf & 


通过 ps -aux | grep redis 命 令 查 看 是 否 启动 ，tail -f nohup.out 碍 看 错误 信 
Ei o 


21.4.4 ”集群 测试 


测试 时 在 主 SSDB/Redis 中 写 入 数据 ， 然 后 从 从 SSDB/Redis 能 读 取 到 数 
据 ， 即 表示 配置 主 从 成 功 。 


测试 商品 基本 信息 SSDB 集 群 。 


root@kaitao:/usr/chapter7# 
/usr/servers/redis-2.8.19/src/redis-cli -p 7770 
127.0.0.1:7770» set i 1 

OK 

127.0.0.1:7770> 

root@kaitao:/usr/chapter7# 
/usr/servers/redis-2.8.19/src/redis-cli -p 7772 
127.0.0.1:7772> get i 

"g" 

测试 商品 介绍 SSDB 集 群 。 
root@kaitao:/usr/chapter7# 
/usr/servers/redis-2.8.19/src/redis-cli -p 8880 
127.0.0.1:8880> set i 1 

OK 

127.0.0.1:8880> 

root@kaitao:/usr/chapter7# 
/usr/servers/redis-2.8.19/src/redis-cli -p 8882 


127.0.0.1:8882> get i 


"q" 
测试 其 他 信息 集群 。 
root@kaitao:/usr/chapter7# 
/usr/servers/redis-2.8.19/src/redis-cli 
127.0.0.1:6660> set i 1 

OK 

127.0.0.1:6660> get i 

"q" 

127.0.0.1:6660> 
root@kaitao:/usr/chapter7# 
/usr/servers/redis-2.8.19/src/redis-cli 
127.0.0.1:6661> get i 


dit Rd 


21.4.5 Twemproxyile. 


-p 6660 


-p 6661 


编辑 /usr/chapter7/nutcracker.yml 配置 文件 。 


basic master: 
listens T7$27.0.0.21: 1413 
hash: fnvla 64 
distribution: ketama 
redis: true 
timeout: 1000 
hash tag: "::" 
servers: 
= 127.0.0.1:27VT70891 serverl 
= 127.0.0.1:7771:1 server2 


basic_slave: 
listen: 127.0.0.1:1112 
hash: fnvla 64 
distribution: ketama 
redis: true 
timeout: 1000 
hash tag: "::" 
servers: 
= 127.04:0.127772:*1 serverl 
= 127.0.0.127717331 server2 


desc master: 
listen: 127.0.0.1:1113 
hash: fnvla 64 
distribution: ketama 
redis: true 
timeout: 1000 
hash tag: "::" 
servers: 
- 127.0.0.1:8880:1 serverl 


. 因为 使 用 了 主 从 ， 所 以 需要 给 Server 起 一 个 名 字 ， 如 serverl 、server2 。 
否则 ， 分 片 算法 默认 根据 ip:port:weight， 这 样 就 会 使 主 从 数据 的 分 片 算法 


不 一 致 。 


因为 其 他 信息 Redis 是 单 实例 全 量 ， 


用 random ° 


- 我们 使 用 了 hash_tag， 可 以 保证 相同 的 tag 在 一 个 分 片上 (本 例 配置 了 ， 


但 没有 用 到 该 特性 ) 


- 127.0.0.1:8881:1 server2 


desc slave: 


listen: 127.0.0.1:1114 
hash: fnvla 64 
distribution: 
true 
1000 


ketama 
redis: 
timeout: 
servers: 
- 127.0.0.1:8882:1 serverl 
= 127.0.0.1:8883:1 server2 


other master: 


listen: 1275.0520.12L115 
hash: fnvla 64 
distribution: 
redis: true 
timeout: 1000 
hash tag: ":: 
servers: 

= 127.0.0.1:6660:1 serverl 


random 


other slave: 


listen: 127.0.0.131116 
hash: fnvla 64 
distribution: 
true 
1000 


Wee "t 
ee 


random 
redis: 
timeout: 

hash tag: 
servers: 

= 127.0.0.1:6661:1 serverl 
- 127.0.0.1:6662:1 server2 


° 


没有 进行 分 乒 ， 因 此 分 片 算 法 可 以 使 


复制 《 跟 我 学 OpenResty (Nginx+Lua) 开发 》 第 6 章 的 nutcracker.init， 并 
把 配置 文件 改 为 usr/chapter7/nutcrackeryml ° 然 后 通 
过 /usr/chapter7/nutcracker.init start 启 动 Twemproxy。 


测试 主 从 集群 是 否 工作 正常 ， 代 码 如 下 。 
root@kaitao:/usr/chapter7# 
/usr/servers/redis-2.8.19/src/redis-cli -p 1111 
127.0.0.1:1111> set i 1 

OK 

127.0.0.1:1111> 

root@kaitao:/usr/chapter7# 
/usr/servers/redis-2.8.19/src/redis-cli -p 1112 
127.0.0.1:1112> get i 

"g" 

127.0.0.1:1112> 

root@kaitao:/usr/chapter7# 
/usr/servers/redis-2.8.19/src/redis-cli -p 1113 
127.0.0.1:1113> seti 1 

OK 

127.0.0.1:1113> 

root@kaitao:/usr/chapter7# 
/usr/servers/redis-2.8.19/src/redis-cli -p 1114 


127.0.0.1:1114> get i 


"q" 
127.0.0.1:1114> 

root@kaitao:/usr/chapter7# 
/usr/servers/redis-2.8.19/src/redis-cli -p 1115 
127.0.0.1:1115> seti 1 

OK 

127.0.0.1:1115> 

root@kaitao:/usr/chapter7# 
/usr/servers/redis-2.8.19/src/redis-cli -p 1116 
127.0.0.1:1116> get i 

"q" 

到 此 数据 集群 配置 成 功 。 


21.5 ”动态 服务 实现 


因为 真实 数据 是 从 多 个 子 系统 获取 ， 很 难 模拟 这 么 多 子 系统 交互 ， 所 以 
此 处 使 用 假 数据 来 进行 实现 。 


21.5.1 项 目 搭建 


使 用 Maven 搭 建 Web 项 目 ，Maven 知 识 请 自行 学 习 。 


21.5.2 WARM 


本 文 将 最 小 化 依赖 ， 即 仅 依 赖 需 要 的 Servlet、Jackson、Guava、Jedis。 


«dependencies» 
«dependency» 
«groupId»javax.servlet«/groupId» 
<artifactId>javax.servlet-api</artifactId> 


<version>3.0.1</version> 
<scope>provided</scope> 

</dependency> 

<dependency> 
<groupId>com. google. guava</groupId> 
<artifactId>guava</artifactId> 
<version>17.0</version> 

</dependency> 

<dependency> 
«groupId»redis.clients«/groupId» 
<artifactId>jedis</artifactId> 
<version>2.5.2</version> 

</dependency> 

<dependency> 
«groupId»com.fasterxml.jackson.core«/groupId» 
<artifactId>jackson-core</artifactId> 
<version>2.3.3</version> 

</dependency> 

<dependency> 
«groupId»com.fasterxml.jackson.corec/groupId» 
<artifactId>jackson-databind</artifactId> 
<version>2.3.3</version> 

</dependency> 

</dependencies> 


guava x& X {lL F apache commons 的 一 个 基础 类 库 ， 用 于 简化 一 些 重复 操 
作 ， 可 以 参考 http:VWifeve.com/google-guava/。 


21.5.3 ”核心 代码 


编辑 com.github.zhangkaitao.chapter7.servlet.ProductServiceServlet 代 码 。 


@Override 
protected void doGet (HttpServletRequest req HttpServletResponse resp) 
throws ServletException, IOException { 
String type = req.getParameter ("type") ; 
String content = null; 
try { 
if ("basic".equals(type)) { 
content = getBasicInfo(req.getParameter ("skuIQ")); 
) else if ("desc".equals(type)) { 
content = getDescInfo(req.getParameter ("skuId")); 
} else if ("other".equals(type)) { 
content = getOtherInfo(req.getParameter ("ps3Id"), 
req. getParameter ("brandId") ); 
} 
} catch (Exception e) { 
e.printStackTrace(); 


resp.setStatus(HttpServletResponse.SC INTERNAL SERVER ERROR); 
return; 


} 

if(content != null) { 
resp.setCharacterEncoding ("UTF-8") ; 
resp.getWriter().write (content); 


} else { 
resp.setStatus (HttpServletResponse.SC_NOT FOUND); 


根据 请 求 参 数 type 来 决定 调用 哪个 服务 获取 数据 。 
1. 基 本 信息 服务 


private String getBasicInfo(String skuId) throws Exception { 
Map<String, Object» map = new HashMap<String, Object>(); 
// 商 品 编号 
map.put("skuId", skuId); 
// 名 称 
map.put("name", "R (Apple) iPhone 6 (A1586) 16GB 金色 移动 联通 电 
信 4G FHL"); 
// 一 级 二 级 三 级 分 类 
map.put("pslId", 9987); 
map.putí("ps2Ild", 653); 
map.pub("ps3Id", :655); 
// 品 牌 ID 
map.put("brandId", 14026); 


// 图 片 列表 


map.put ("imgs", 


/ / 上架 时 间 


map.put ("date", 


// 商 品 毛重 
map.put("weight", "400"); 
/ / MERE 


map.put ("colorSize", 


// 扩 展 属性 


map.put("expands", 


// 规 格 参 数 


map.put ("propCodes", 
map.put ("date", 


getImgs (skuId)); 


"2014-10-09 22:29:09"); 


getColorSize(skuld)); 


getExpands (skuId)); 


getPropCodes (skuId)); 
System.currentTimeMillis()); 


String content - objectMapper.writeValueAsString (map); 


/ /实际 应 用 应 该 是 发 送 MQ 


asyncSetToRedis (basicInfoJedisPool, 


return objectMapper.writeValueAsString (map); 


private List«String» getImgs(String skuld) { 


return Lists.newArrayList( 


private List<Map<String, 
return Lists.newArrayList( 


ny 十 skuId+ Migs 


content); 


"jfs/t277/193/1005339798/768456/29136988/54240798N19d42ce3. jpg", 
"jfs/t352/148/1022071312/209475/53b8cd7£/5424079bN3ea45c98. jpg", 
"j£s/t274/315/1008507116/108039/£70cb380/542d0799Na03319e6. jpg", 
"jfs/t337/181/1064215916/27801/0)05026705/5428079aNf184ce18. jpg" 


makeColorSize (1217499, 
makeColorSize(1217500, 
makeColorSize (1217501, 
makeColorSize (1217508, 
makeColorSize (1217509, 
makeColorSize (1217509, 
makeColorSize (1217493, 
makeColorSize (1217494, 
makeColorSize (1217495, 
makeColorSize (1217503, 
makeColorSize (1217503, 
makeColorSize (1217504, 
makeColorSize(1217505, 


"gE", "公开 版 (16GB ROM) "), 
"TRASK", "公开 版 (16GB ROM) "), 
"银色 "， "公开 版 (16GB ROM) "), 
"fen, "公开 版 (64GB ROM) "), 
" 深 空 灰 "， "公开 版 (64GB ROM) "), 
"银色 "， "公开 版 (64GB ROM) "), 


"金色 "， "移动 4G 版 
"TREK", "移动 4G 版 
"银色 "， "移动 4G 版 
"金色 "， "移动 4G 版 
"金色 "， "移动 4G 版 
"RER", "移动 4G 版 
"银色 "， "移动 4G 版 


(16GB) "), 
(16GB) "), 
(16GB) "), 
(64GB) "), 
(64GB) "), 
(64GB) "), 
(64GB) ") 


Object»» getColorSize(String skuId) { 


) 
private Map<String, Object» makeColorSize(long skuId, String color, 
String size) ( 
Map<String, Object» csl = Maps.newHashMap(); 
csl.put("SkuId", skuId); 
csl.put("Color", color); 
csl.put("Size", size); 
return csl; 


private List<List<?>> getExpands(String skuId) { 
return Lists.newArrayList( 
(List<?>) Lists.newArrayList ("4Asi", Lists.newArrayList ("iH 
87mm AF", "xf NEC"), 
(List«?»)Lists.newArrayList(" ZR", "ÆR (IOS) "), 
(List<?>) Lists.newArrayList ("#Zt", "苹果 (IOS) "), 
(List<?>) Lists.newArrayList (" 购 买方 式 "，" 非 合约 机 ") 


private Map<String, List<List<String>>>getPropCodes (String skuId) { 

Map<String, List<List<String>>> map = Maps.newHashMap () ; 

map.put ("Ef*", Lists.<List<String>>newArrayList ( 
Lists.<String>newArrayList ("Anh#", "苹果 (Apple) "), 
Lists.<String>newArrayList ("4J45", "iPhone 6 A1586"), 
Lists.<String>newArrayList (" 颜 色 "，" 金 色 ") ， 
Lists.<String>newArrayList ("上 市 年 份 "，"2014 Æ") 

)); 

map.put ("4Fffi", Lists.<List<String>>newArrayList ( 
Lists.<String>newArrayList ("机 身 内 存 "，"16GB ROM"), 
Lists.<String>newArrayList ("储存 卡 类 型 "，" 不 支持 ") 

DE 

map .put ("显示 "，Lists.<List<String>>newArrayList( 
Lists.«String»newArrayList ("屏幕 尺寸 "，"4.7 英寸 ") ， 
Lists.<String>newArrayList (" 触 摸 屏 "， "Retina HD"), 
Lists.<String>newArrayList (" 分 辨 率 "，"1334 x 750") 

) ) 

return map; 


} 
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格 参数 等 数据 。 而 为 了 简化 逻辑 ， 大 多 数 数据 都 是 LisVMap 数 据 结构 。 


2. 商 品 介绍 服务 


private String getDescInfo(String skuId) throws Exception { 

Map«String, Object» map = new HashMap<String, Object>(); 

map.put("content", "<div><img data -lazyload-'http:// img30. 
360buyimg.com/jgsq-productsoa/jfs/t448/127/574781110/103911/53c80634/5472 
ba22N45400f4e.jpg' alt-'' /><img data-lazyload-'http:// img30.360buyimg. 
com/jgsq-productsoa/jfs/t802/133/19465528/162152/e463e43/54e2b34aN11bceb7 
0.jpg' alt='' height='386' width='750' /></div>"); 

map.put("date", System.currentTimeMillis()); 

String content = objectMapper.writeValueAsString (map); 

// 实 际 应 用 应 该 是 发 送 MO 

asyncSetToRedis (descInfoJedisPool, "d:" + skuId + ":", content); 

return objectMapper.writeValueAsString (map); 


) 


3. 其 他 信息 服务 


private String ge tOtherInfo(String ps3Id, String brandId) throws 
Exception { 

Map«String, Object» map = new HashMap<String, Object>(); 

// 面 包 导 

List<List<?>> breadcrumb = Lists.newArrayList(); 

breadcrumb.add(Lists.newArrayList (9987, "手机 ")); 

breadcrumb.add(Lists.newArrayList (653, "手机 通讯 ")) 

breadcrumb.add(Lists.newArrayList(655, "手机 ")); 

/ | és 

Map<String, Object» brand = Maps.newHashMap(); 

brand.put("name", "苹果 (Apple) "); 

brand.put ("logo", 

"BrandLogo/g14/M09/09/10/rBEhVlK6vdkIAAAAAAAFLXzp-lIAAHWawP QjwAAAVF472.png"); 

map.put("breadcrumb", breadcrumb); 

map.put("brand", brand); 

// 实 际 应 用 应 该 是 发 送 MO 

asyncSetToRedis (otherInfoJedisPool, "s:" + ps3Id + ":", 
objectMapper.writeValueAsString (breadcrumb) ) ; 

asyncSetToRedis (otherInfoJedisPool, "b:" + brandId + ":", 
objectMapper.writeValueAsString (brand) ) ; 

return objectMapper.writeValueAsString (map) ; 
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4. 辅 助 工 具 


private ObjectMapper objectMapper = new ObjectMapper(); 

private JedisPool basicInfoJedisPool = «eateJedisPool("127.0.0.1", 1111); 
private JedisPool descInfoJedisPool = createJedisPool("127.0.0.1", 1113); 
private JedisPool otherInfoJedisPool = createJedisPool ("127.0.0.1", 1115); 


private JedisPool createJedisPool(String host, int port) { 
GenericObjectPoolConfig poolConfig = new GenericObjectPoolConfig(); 
poolConfig.setMaxTotal (100); 
return new JedisPool(poolConfig, host, port); 


private ExecutorService executorService = Executors.newFixedThreadPool (10); 
private void asyncSetToRedis(final JedisPool jedisPool, final Sring 
key, final String content) { 
executorService.submit(new Runnable() { 
QOverride 
public void run() { 
Jedis jedis = null; 
try { 
jedis = jedisPool.getResource(); 
jedis.set(key, content); 
) catch (Exception e) { 
e.printStackTrace(); 
jedisPool.returnBrokenResource(jedis); 
) finally ( 
jedisPool.returnResource(jedis); 


kr 


本 例 使 用 Jackson 进 行 JSON 的 序列 化 。Jedis 进 行 Redis 的 操作 。 使 用 线程 池 
做 异步 更 新 (实际 应 用 中 ， 可 以 使 用 MQ 做 实现 ) 。 


21.5.4 ”web.xml 配置 


<servlet> 


<servlet-name>productServiceServlet</servlet-name> 


<servlet-class>com.github.zhangkaitao.chapter7.servlet.ProductServiceServ 
let</servlet-class> 


</servlet> 

<servlet-mapping> 
<servlet-name>productServiceServlet</servlet-name> 
<url-pattern>/info</url-pattern> 

</servlet-mapping> 


21.5.55 打 WAR 包 


cd D:\workspace\chapter7 


mvn clean package 


此 处 使 用 maven 命 令 打 包 ， 比 如 本 例 将 得 到 chapter7.war， 然 后 将 其 上 传 到 
服务 絮 的 /usr/chapter7/webapp， 然 后 通过 unzip chapter6.war 解 压 。 


21.5.6 Ace Tomcat 

复制 《 跟 我 学 OpenResty (Nginx*Lua) 开发 》 第 6 章 使 用 的 Tomcat 实 例 。 
cd /usr/servers/ 

cp -r tomcat-server1 tomcat-chapter7/ 

vim /usr/servers/tomcat-chapter7/conf/Catalina/localhost/ROOT.xml 

<!-- 访问 路 径 是 根 ，Web 应 用 所 属 目 录 为 /usr/chapter7/webapp --> 


<Context path="" docBase="/usr/chapter7/webapp"></Context> 


指向 第 7 章 的 Web 应 用 路 径 。 


21.5.7. iX 


启动 Tomcat 实 例 。 


/usr/servers/tomcat-chapter7/bin/startup.sh 

访问 如 下 URL 进 行 测试 。 
http://192.168.1.2:8080/info?type=basic&skuld=1 
http://192.168.1.2:8080/info?type=desc&skuld=1 


http://192.168.1.2:8080/info?type=other&ps3Id=1&brandId=1 


21.5.8 Nginx 配 置 
编辑 /usrchapter7mmginx_chapter7.conf 配 置 文件 。 


upstream backend { 


server 127.0.0.1:8080 max fails-5 fail timeout-10s weight=1; 

check interval-3000 rise-1 fall=2 timeout=5000 type-tcp default _ dow 
-false; 

keepalive 100; 


server { 
listen 80; 
server name item2015.jd.com item.jd.com d.3.cn; 


location ~ /backend/(.*) ( 
#internal; 
keepalive timeout 30s; 
keepalive requests 1000; 
FX FE keep-alive 
proxy http version 1.1; 
proxy set header Connection ""; 


rewrite /backend(/.*) $1 break; 

proxy pass request headers off; 

#more clear input headers Accept-Encoding; 
proxy next upstream error timeout; 

proxy pass http://backend; 


此 处 server_name 指 定 了 item.jd.com 《商品 详情 页 ) 和 d.3.cn (商品 介 
绍 ) 。 其 他 配置 可 以 参考 第 6 章 的 内 容 。 另 外 ， 实 际 生 产 环境 要 把 
#internal 打 开 ， 表 示 只 有 本 Nginx 能 访问 。 

编辑 /usr/servers/nginx/conf/nginx.conf 配置 文件 。 

include /usr/chapter7/nginx chapter7.conf; 

# 为 了 方便 测试 ， 注 释 挥 example.conf 

include /usr/chapter6/nginx_chapter6.conf; 

#ua 模 块 路 径 ， 其 中 ";;" 表 示 默 认 搜 索 路 径 ， 默 认 到 /usr/servers/nginx 下 找 
lua package path "/usr/chapter7/lualib/?.lua;;"; #lua 模块 

lua package cpath "/usr/chapter7/lualib/?.so;;"; #c 模 块 

Lua 模 块 从 /usr/chapter7 目 录 加 载 ， 因 为 我 们 要 使 用 自己 写 的 模块 。 

HEJA Nginx ° 


/usr/servers/nginx/sbin/nginx -s reload 


21.5.9” 绑 定 hosts 测 试 


192.168.1.2 item.jd.com 
192.168.1.2 item2015.jd.com 
192.168.1.2 d.3.cn 
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21.6 Bi? EZ S EA 

分 为 三 部 分 实现 : 基础 组 件 、 商 品 介绍 、 前 端 展 示 部 分 。 


21.6.1 ”基础 组 件 


首先 ， 进 行 基础 组 件 的 实现 ， 两 品 介 介绍 和 前 端 展 示 部 分 都 需要 读 取 Redis 
和 HTTP 服 务 ， 因 此 ， 可 以 抽取 公共 部 分 出 来 复 用 。 


编辑 /usrchapter7/lualibyitem/common.lua 代 码 。 


local redis = require("resty.redis") 
local ngx log - ngx.log 
local ngx ERR - ngx.ERR 
local function close redis (red) 

if not red then 

return 

end 

-- 释 放 连 接 (连接 池 实 现 ) 
local pool max idle time = 10000 -- 毫 秒 
local pool size = 100 -- 连 接 池 大 小 
local ok, err = red:set keepalive (Pool max idle time, pool size) 


if not ok then 
ngx log(ngx ERR, "set redis keepalive error : ", err) 
end 

end 


local function read redis(ip, port, keys) 


local red = redis:new() 

red:set timeout (1000) 

local ok, err - red:connect(ip, port) 

if not ok then 
ngx log(ngx ERR, "connect to redis error Wy EX) 
return close redis (red) 

end 

local resp = nil 

if #keys == 1 then 
resp, err = red:get(keys[1]) 

else 
resp, err - red:mget(keys) 

end 

if not resp then 
ngx log(ngx ERR, "get redis content error ", ‘err) 
return close redis (red) 

end 

-- 得 到 的 数据 为 空 处 理 

if resp == ngx.null then 
resp = nil 

end 

close redis (red) 

return resp 

end 
local function read http (args) 
local resp = ngx.location.capture("/backend/info", { 


end 


method = ngx.HTTP GET, 
args — args 


}) 


if not resp then 
ngx log(ngx ERR, "request error") 
return 

end 

if resp.status -- 200 then 
ngx log(ngx ERR, "request error, status 
return 

end 

return resp.body 


, 


resp.status) 


local M=  { 
read redis = read redis, 
read http - read http 

} 


return M 


整个 逻辑 和 第 6 章 类 似 。 只 是 read_redis 根 据 参数 keys 个 数 支 持 get 和 mget。 
比如 ，read_redis(ip, port, {"key1"}), ， 则 调用 get ， 而 read_redis(ip,， port, 
{"key1", "key2"}), 则 调用 mget o 


21.6.2 ”商品 介绍 
1. 核 心 代码 
编辑 /usr/chapter7/desc.lua 代 码 。 


local common = require ("item.common") 
local read redis - common.read redis 
local read http - common.read http 
local ngx log = ngx.log 

local ngx ERR = ngx.ERR 

local ngx exit = ngx.exit 

local ngx print = ngx.print 

local ngx_re match = ngx.re.match 
local ngx var = ngx.var 


local descKey = "d;i" .. skuId s. ":" 
local descInfoStr = read redis("127.0.0.1", 1114, {descKey}) 
if not descInfoStr then 
ngx_log(ngx_ERR, "redis not found desc info, back to http, skuId : ", 
skuld) 
descInfoStr = read_http({type="desc", skuId = skuId}) 
end 
if not descInfoStr then 
ngx_log(ngx ERR, "http not found basic info, skuId : ", skuld) 


return ngx exit(404) 
end 
ngx print ("showdesc(") 
ngx print (descInfoStr) 
hgx print([")") 


通过 复 用 逻辑 后 ， 整 体 代 码 简 化 了 许多 。 此 处 从 集群 读 取 商品 介绍 。 男 
外 ， 前 端 展示 使 用 JSONP 技 术 展 示 商 品 介绍 。 


2.Nginx 配 置 


编辑 /usr/chapter7/nginx_chapter7.conf 配置 文件 。 


location -^/desc/(Nd*)$ { 

if (Shost != "d.3.cn") { 

return 403; 

} 

default type application/x-javascript; 

charset utf-8; 

lua code cache on; 

set $skuId $1; 

content by lua file /usr/chapter7/desc.lua; 
) 


因为 item.jd.com 和 d.3.cn 复 用 了 同一 个 配置 文件 ， 此 处 需要 限定 只 有 d.3.cn 
域名 能 访问 ， 以 防止 恶意 访问 。 


重启 Nginx 后 ， 访 问 http://d.3.cn/desc/1 即 可 得 到 JSONP 结 


21.6.3 “前端 展示 

1. 核 心 代码 

编辑 /usr/chapter7/item.lua 代 码 。 

local common = require("item.common") 
local item = require(" item") 

local read. redis = common.read redis 
local read, http = common.read http 
local cjson = require("cjson") 


local cjson decode = cjson.decode 


local ngx log = ngx.log 
local ngx ERR = ngx.ERR 
local ngx exit = ngx.exit 
local ngx print = ngx.print 
local ngx var 7 ngx.var 


local skuld = ngx_var.skuld 


-- 获 取 基 本 信息 


local basicInfoKey = "p:" .. skuId .. ":" 
local basicInfoStr = read redis("127.0.0.1", 1112, [(basicInfoKey]) 
if not basicInfoStr then 
ngx log(ngx ERR, "redis not found basic info, back to http, skuId : " 
skuld) 
basicInfoStr = read http((type-"basic", skuId = skuId]) 
end 
if not basicInfoStr then 
ngx log(ngx ERR, "http not found basic info, skuId : ", skuId) 
return ngx exit (404) 
end 


local basicInfo - cjson decode (basicInfoStr) 
local ps3Id = basicInfo["ps3Id"] 
local brandId = basicInfo["brandId"] 


-- 获 取 其 他 信息 
local breadcrumbKey = "s:" .. ps3Id .. ":" 
local brandKey = "b:" .. brandId ..":" 


local otherInfo = readredis("127.0.0.1", 1116, {breadcrumbKey, brandKey)} 
or {} 

local breadcrumbStr = otherInfo[1] 

local brandStr = otherInfo[2] 

if breadcrumbStr then 


basicInfo["breadcrumb"] - cjson decode (breadcrumbStr) 
end 
if brandStr then 

basicInfo["brand"] = cjson decode (brandStr) 
end 


if not breadcrumbStr and not brandStr then 


, 


ngx log(ngx ERR, "redis not found other info, back to http, skuId : ", 


brandId) 
local otherInfoStr - read http((type-"other", ps3Id - ps3Id, brandId 
= brandId]) 
if not otherInfoStr then 
ngx log(ngx ERR, "http not found other info, skuId : ", skuId) 
else 
local otherInfo - cjson decode (otherInfoStr) 
basicInfo["breadcrumb"] = otherInfo["breadcrumb"] 
basicInfo["brand"] = otherInfo["brand"] 
end 


end 


local name = basicInfo["name"] 
--name to unicode 


basicInfo["unicodeName"] = item.utf8 to unicode(name) 
-- 字 符 串 截取 ， 超 长 显示 .… 
basicInfo["moreName"] = item.trunc(name, 10) 
-- 初 始 化 各 分 类 的 URL 

item.init breadcrumb(basicInfo) 

-- 初 始 化 扩展 属性 

item.init expand(basicInfo) 

-- 初 始 化 颜色 斥 码 
item.init color size(basicInfo) 

local template = require "resty.template" 
template.caching(true) 


template.render("item.html", basicInfo) 


整个 逻辑 分 为 四 部 分 ， 获取 基本 信息 ， 根 据 基 本 信息 中 的 关联 关系 获取 
其 他 信息 初始 化 /格式 化 数据 泻 染 模板 。 


2. 初 始 化 模块 


编辑 /usr/chapter7/lualib/item.lua 代 码 。 


local bit = require("bit") 
local utf8 = require ("utf8") 


local cjson = require("cjson") 


local cjson encode - cjson.encode 


local bit band - bit.band 


logal bit bor = bit.bor 
löcal bit LBATIL = Dlt lshitt 


local string format = string.format 
local string byte = string. byte 


local table concat = table.concat 


--utf8 4@A unicode 
local function utf8 to unicode (str) 


if not str or str == "" or str == ngx.null then 
return nil 

end 

local res, seq, val = {}, 0, nil 


for i= 1, #str do 
local c = string byte(str, i) 
if seq -- 0 then 
if val then 
res[#res + 1] = string format("$04x", val) 
end 


seq = c < 0x80 and 1 or c < OxEO and 2 or c < OxFO and 3 or 


C < OxF8 and 4 or --c < OxFC and 5 or c < OxFE and 6 or 0 
if seq -- 0 then 
ngx.log(ngx.ERR, 'invalid UTF-8 character sequence' 
"sri" ee VOSUXlng(str)) 
return str 
end 


val = bit band(c, 2 ^ (8 = seq) - 1) 
else 
val 


Il 


bit bor(bit lshift(val, 6), bit band(c, Ox3F)) 
end 
seq = seq- 1 
end 
if val then 
res[#res + 1] = string format("$04x", val) 
end 
if #res == 0 then 
return str 
end 
return "\\u" .. table concat(res, "\\u") 
end 


--utf8 字符 串 截取 
local function trunc(str, len) 
if not str then 
return nil 
end 


if utf8.len(str) » len then 
return tte eu tet, l, Den) es '"..." 
end 
return str 
end 


-- 初 始 化 面包 履 
local function init breadcrumb (info) 
local breadcrumb = info["breadcrumb"] 
if not breadcrumb then 
return 
end 


local pslid breadcrumb[1][1] 
local ps2Id = breadcrumb[2] [1] 
local ps3Id breadcrumb [3] [1] 


-此 处 应 该 根据 一 级 分 类 查找 url 

local pslUrl = "http://shouji.jd.com/" 

local ps2Url = "http://channel.jd.com/shouji.html" 

local ps3Url = "http://list.jd.com/list.html?cat-" 
a ps2rd s "," ss ps3Id 


breadcrumb[1] [3] = ps1Url 
breadcrumb[2] [3] = ps2Url 
breadcrumb [3] [3] = ps3Url 
end 
-- 初 始 化 扩展 属性 


local function init expand (info) 
local expands = info["expands"] 
if not expands then 


return 
end 
for , e in ipairs(expands) do 
if type(e[2]) == "table" then 
l2] = table concat(e[2], "s ") 
end 
end 
end 
-- 初 始 化 颜色 尺码 


local function init color size(info) 
local colorSize = info["colorSize"] 


--Bit& RIG Json 串 

local colorSizeJson = cjson encode (colorSize) 
-- 颜 色 列 表 〈 不 重复 ) 

local colorList = {} 

-- 尺 码 列表 不 重复 ) 


local sizeList = {} 


info["colorSizeJson"] = colorSizeJson 
info["colorList"] = colorList 
info["sizeList"] = sizeList 


local colorSet = {} 

local sizeSet = {} 

for , cz in ipairs(colorSize) do 
local color = oez["Color"] 
local size = cz["Size"] 


«e pslld. 4. 


" 


y 


if color and color ~= "" and not colorSet[color] then 


colorList[#colorList + 1] = {color = color, 
url = "http://item.jd.com/" .;cz["Skuld"] s» ".Hhtml") 
colorSet[color] = true 
end 
if size and size ~= "" and not sizeSet[size] then 
sizeList[#sizeList + 1] = {size = size, 
url = "http://item.jd.com/" ..cz["SkuId"] .. ".html") 
SizeSet[size] = "" 
end 
end 
end 


lecal M= { 
utf8 to unicode = utf8 to unicode, 


trunc = trunc, 

init breadcrumb - init breadcrumb, 
init expand - init expand, 

init color size = init color size 


return M 
utf8_to_unicode 代 码 之 前 已 经 见 过 了 ， 其 他 的 都 是 一 些 逻 辑 代 码 。 
3. 模 板 HTML 片段 


编辑 /usr/chapter7/item.html 文 件 。 


var pageConfig = { 

compatible: true, 

product: { 
skuidi {* skuId *}, 
name: '{* unicodeName *}', 
skuidkey: 'AFC266E971535B664FC926D34E91C879', 
href: 'http://item.jd.com/(* skuId *}.html', 
Sra: "{* smgslL] ah", 
cat? [{* psLId *},{* ps2Id *},{* ps3id *}], 
brand: {* brandId *}, 
tips: false, 
pType: 1, 
venderId:0, 
shopId:'0', 


specialAttrs: ["HYKHSP-0","isDistribution", "isHaveYB","isSelfService-0", "i 


sWeChatStock-0", "packType", "IsNewGoods", "isCanUseDQ", "isSupportCard", "isC 
anUseJQ", "isOverseaPurchase-0","is7ToReturn-1","isCanVAT"], 

videoPath:'', 

desc: 'http://d.3.cn/desc/(* skuId *)' 


i 
var warestatus = 1; 
$ if colorSizeJson then $) var ColoiSize = {* cdorSizeJson *};{% 
end %} 


(* var *} 输 出 变量 ，{% code %} 写 代 码 片段 。 
Hae 


«div class-"breadcrumb"» 
«strong» 
<a href-'(* breadcrumb[1][3] *}'>{* breadcrumb[1] [2] *}</a><4trong> 
<span> 
&nbsp; &gt; &nbsp; 
<a href='{* breadcrumb[2][3] *}'>{* breadcrumb[2] [2] *}</a> 
&nbsp; &gt; &nbsp; 
<a href='{* breadcrumb[3][3] *}'>{* breadcrumb[3] [2] *}</a> 
&nbsp; &gt; &nbsp; 
</span> 
<span> 
($ if brand then $) 
«a href-'http://www.jd.com/pinpai/(* ps3Id *}-{* brandId *}. 
html'>{* brand['name'] *)«/a» 
&nbsp; &gt; &nbsp; 
$ end $) 
<a href-'http://item.jd.com/(* skuId *}.html'>{* moreName *}</a> 
</span> 
</div> 


图 片 列表 


<div id-"spec-n1" class="jqzoom" onclick="window.open('http:// www.jd. 
com/bigimage.aspx?id-(* skuId *)')" clstag-"shangpin|keycount |product| 
spec-nl"> 
<img data-img="1" width="350" height="350" src-"http://imgl4. 
360buyimg.com/nl/(* imgs[1] *}" alt="{* name *}"/> 


</div> 

<div id="spec-list" clstag-"shangpin|keycount|product|spec-n5"» 
<a href="javascript:;" class="spec-control" id="spec-forward"></a> 
<a href="javascript:;" class="spec-control" id="spec-backward"></a> 


<div class-"spec-items"» 


«ul class-"lh"» 
$ for , img in ipairs(imgs) do %} 
<li><img class='img -hover' alt='{* name *)' src='http:// 
imgl4.360buyimg.com/n5/(* img * }' data -url='{* img *}' data -img='1' 
width='50' height='50'></1i> 
($ end %} 
«/ul» 
</div> 
</div> 


颜色 尺码 选择 


«div class="dt"> 选 择 颜色 :</div> 
<div class="dd"> 
$ for , color in ipairs(colorList) do $] 
<div class="item"><b></b><a href-"(* color['url'] *}" title= 
"{* color['color'] *}"><i>{* color['color'] *}</i></a></div> 
($ end %} 
«/div» 
</div> 
<div id="choose-version" class-"li"» 
<div class="dt"> 选 择 版 本 : </div> 
<div class="dd"> 
{ for , size in ipairs(sizeList) do %} 
<div class="item"><b></b><a href="{* size['url'] *}" title= 
"{* size['size'] *}">{* size['size'] *}</a></div> 
($ end $} 
</div> 
</div> 


扩展 属性 


<ul id="parameter2" class-"p-parameter-list"» 

«li title-'(* name *J'»fji ZW: (* name *)«/li» 

«li title-'(* skuId *)'»i S: (* skuId *)«/li» 

($ if brand then $} 

«li title-'(* brand["name"] *} Half: «a href-'http://www.jd.com/pinpai/(* 
ps3Id *}-{* brandId *J.html' target-' blank'>{* brand["name"] *}</a></1li> 

($ end $] 

($ if date then %} 

«li title-'(* date *}'> 上 架 时 间 : (* date *)«/li» 

($ end 3} 

($ if weight then $) 

<li title-'(* weight *}'> 商 品 毛重 : {* weight *)«/li» 

($ end $} 


($ for , e in pairs(expands) do $] 
«li title-'(* e[2] *}'>{* e[1] *}: (* e[2] *J«/1i» 
($ end %} 

</ul> 


规格 参数 


«table cellpadding="0" cellspacing-"1" width="100%" border="0" class="Ptable"> 
{% for group, pc in pairs(propCodes) do %} 
<tr><th class="tdTitle" colspan="2">{* group *}</th><tr> 


($ for , v in pairs(pc) do %} 
<tr><td class="tdTitle">{* v[1] *}</td><td>{* v[2] *}</td></tr> 
($ end $) 
($ end %} 
</table> 
4.Nginx 配 置 
编辑 /usr/chapter7/nginx_chapter7.conf 配置 文件 。 
# 模 板 加 载 位 置 


set $template root "/usr/chapter7"; 
location ~ ^/(Nd*).html$ { 
if (Shost la "^(item|item2015)N.jdN.com$") 1 
return 403; 
} 
default type 'text/html'; 
charset utf-8; 
lua code cache on; 
set $skuId $1; 
content by lua file /usr/chapter7/item.lua; 


} 


21.6.4 测试 


重启 Nginx， 访 问 http://item.jd.com/1217499.html 可 得 到 响应 内 容 ， 本 例 和 
京东 的 商品 详情 页 的 数据 有 些 出 入 ， 因 为 输出 的 页 面 做 了 一 些 精简 。 


21.6.5 ”优化 


1.local cache 


对 于 数据 一 致 性 有 要 求 不 敏感 ， 而 且 数 据 量 很 少 的 其 他 信息 ， 完 全 可 以 在 
本 地 缓存 全 量 。 而 且 可 以 设置 5~10 分 钟 的 过 期 时 间 ， 这 是 完全 可 以 接受 
的 。 因 此 ， 可 以 使 用 


lua_shared_dict 全 局 内 存 进 行 缓存 。 有 具体 逻辑 可 以 参考 如 下 代码 。 


local nginx shared = ngx.shared 
--item.jd.com 配 置 的 缓存 
local local cache = nginx shared.item local cache 
local function cache get(key) 

if not local cache then 

return nil 

end 

return local cache:get (key) 
end 


local function cache set(key, value) 
if not local cache then 
return nil 
end 
return local cache:set(key, value, 10 * 60) --10 分 钟 
end 


local function get(ip, port, keys) 
local tables = {} 
local fetchKeys = {} 
local resp = nil 
local status = STATUS OK 
-- 如 果 tables 是 个 map， 则 #tables 拿 不 到 长 度 
local has value = false 
-- 先 读 取 本 地 缓存 


for i, key in ipairs(keys) do 


local value = cache get (key) 
if value then 

if value -- "" then 

value - nil 

end 

tables[key] = value 

has value = true 
else 

fetchKeys[#fetchKeys + 1] = key 
end 


end 


-- 如 果 还 有 数据 没 获 取 ， 则 从 Redis 获取 
if #fetchKeys > 0 then 
if #fetchKeys == 1 then 
status, resp = redis get(ip, port, fetchKeys[1]) 


else 
status, resp - redis mget(ip, port, fetchKeys) 
end 
if status == STATUS OK then 
for i= 1, #fetchKeys do 
local key = fetchKeys[i] 
local value = nil 
if #fetchKeys == 1 then 
value = resp 


else 


value = get data(resp, i) 


end 
tables[key] = value 
has value = true 
cache set(key, value or "", ttl) 
end 
end 
end 
-- 如 果 从 绥 存 查 到 ， 那 么 就 认为 ok 
if has value and status -- STATUS NOT FOUND then 
Status — STATUS OK 
end 
return status, tables 


end 


2.nginx proxy cache 


为 了 防止 恶意 刷 页 面 或 热点 页 面 访问 频繁 ， 可 以 使 用 nginx proxy. cache 
页 面 缓存 。 当然， 还 可 以 选择 Apache Traffic Server、Squid、Varnish 等 做 
内 容 缓存 。 


nginx.conf 缓 存 配 置 


proxy buffering on; 

proxy buffer size 8k; 

proxy buffers 256 8k; 

proxy busy buffers size 64k; 
proxy temp file write size 64k; 


proxy temp path /usr/servers/nginx/proxy temp; 
HX E Web 缓存 区 名 称 为 cache_one， 内 存 缓存 空间 大 小 为 200MB，1 分 钟 没有 被 访问 的 
# 内 容 自动 清除 ， 硬 盘 缓 存 空间 大 小 为 30GB。 
proxy cache path /usr/servers/nginx/proxy cache levels=1:2 
keys zone-cache item:200m inactive-1m max size-309g; 


增加 proxy_cache 的 配置 ， 可 以 通过 挂 载 一 块 内 存 作 为 缓存 的 存储 空间 。 
更 多 配 置 规 则 请 参 * 
http://nginx.org/cn/docs/http/ngx http proxy module.html ° 


nginx_chapter7.conf 配 置 
与 server 指 令 配置 同 级 。 


Hee eee HAE 测试 时 使 用 的 动态 请 求 

map $host $item dynamic { 
default TOMS 
item2015.jd.com ENS 


即 如 果 域 名 为 item2015.jd.com， 则 item_dynamic=1 ° 


location ~ ^/(Nd*).html$ { 
set $skuId $1; 
if ($host !~ "*(item|item2015)\.jd\.com$") { 
return 403; 


expires 3m; 

proxy cache cache item; 

proxy cache key $uri; 

proxy cache bypass $item dynamic; 

proxy no cache $item dynamic; 

proxy cache valid 200 301 3m; 

proxy cache use stale updating error timeout invalid header 
http 500 http 502 http 503 http 504; 

proxy pass request headers off; 

proxy set header Host $host; 

# 支 持 keep-alive 

proxy http version 1.1; 

proxy set header Connection ""; 

proxy pass http://127.0.0.1/proxy/S$skuId.html; 

add header X-Cache 'S$upstream cache status'; 


location ~ ^/proxy/(Nd*).html$ { 
allow 127.0.0.1; 
deny all; 
keepalive timeout 30s; 
keepalive requests 1000; 
default type 'text/html'; 
charset utf-8; 
lua code cache on; 


set $skuId $1; 
content by lua file /usr/chapter7/item.1lua; 


expires: 设置 啊 应 缓存 头 信息 ， 此 处 是 3min。 将 会 得 到 Cache- 
Control:max-age=180 和 类 似 Expires:Sat, 28 Feb 2015 10:01:10 GMT 的 啊 应 
3L. o 


proxy cache: 使 用 之 前 在 nginx.conf 中 配置 的 cache itemZ& 1f ° 


proxy cache key: 缓存 key 为 URI， 不 包括 Host 和 参数 ， 这 样 不 管用 户 怎 
么 通过 在 URL 上 加 随机 数 都 是 可 以 缓存 的 。 


proxy cache bypass: ”Nginx 不 从 缓存 读 取 响应 的 条 件 ， 可 以 写 多 个 。 如 
果 存 在 一 个 字符 串 条 件 旦 不 是 <0”"， 那 么 Nginx 束 不 会 从 缓存 中 读 取 了 响应 
内 容 。 此 处 ， 如 果 使 用 的 host 为 item2015.jdcom， 那 么 就 不 会 从 缓存 读 取 
响应 内 容 。 


proxy no cache: Nginx 不 将 响应 内 容 写 入 缓存 的 条 件 ， 可 以 写 多 个 。 如 
条 存在 一 个 字符 串 条 件 且 不 是 “0”， 那 么 Nginx 惑 个 会 将 响应 内 容 写 入 组 
存 。 此 处 ， 如 果 使 用 的 host 为 item2015.jd.com， 那 么 就 不 会 将 啊 应 内 容 写 
入 缓存 。 


proxy cache valid: 为 不 同 的 啊 应 状态 码 设置 不 同 的 缓存 时 间 ， 此 处 对 
200、301 缓 存 3min ° 


proxy cache use stale: 什么 情况 下 使 用 不 新 鲜 (过 期 ) 的 缓存 内 容 。 
配置 和 proxy_next_upstream 内 容 类 似 。 此 处 配置 了 如 果 出 现 连 接 出 错 、 超 
时 、404、500 等 问题 ， 都 会 使 用 不 新 鲜 的 缓存 内 容 。 此 外 我 们 配置 了 
updating 配 置 ， 通 过 配置 它 可 以 在 Nginx 更 新 缓存 (其 中 一 个 Worker 进 
FR) 时 (其 他 的 Worker 进 程 ， 使 用 不 新 鲜 的 缓存 进行 响应 ， 这 样 可 以 减 
少 回 源 的 数量 。 


proxy. pass request headers: 不 需要 请 求 头 ， 所 以 不 传递 。 


proxy_http_version 1.1 和 proxy set header Connection "" : 支持 
keepalive ° 


add header X-Cache '$upstream_cache_status': 3 JL e e e f PY RR 
应 头 。 比 如 命中 HIT、 不 命中 MISS、 不 走 缓存 BYPASS。 或 者 命中 会 看 到 
X-Cache: HITI% ° 

allow/deny: 人 允许 和 拒绝 访问 的 了 列表 ， 此 处 只 允许 本 机 访问 。 

keepalive timeout 30s 和 keepalive_requests 1000: ”支持 keepalive。 


nginx_chapter7.conf 清 理 绥 存 配置 。 


location /purge { 


allow T1277 0:20 sks 
allow 192.168.0.0/16; 
deny all; 


proxy cache purge cache item $arg url; 


} 


只 允许 内 网 访问 。 访 问 如 http://item.jd.com/purge?url=/11.html。 如 果 看 到 
Successful purge， 则 说 明 缓 存 存在 并 已 经 清理 了 。 


修改 item.lua 代 码 
-- 添 加 Last-Modified， 用 于 啊 应 304 绥 存 


ngx.header["Last-Modified"] = ngx.http_time(ngx.now()) 
local template = require "resty.template" 
template.caching(true) 


template.render("item.html", basicInfo) 


在 泻 染 模 板 前 设置 Last-Modified， 用 于 判断 内 容 是 否 变 更 ， 默 认 Nginx 通 
过 等 于 去 比较 ， 也 可 以 通过 配置 if_modified_since 指 令 来 支持 小 于 等 于 比 
较 。 如 果 请 求 头发 送 的 If-Modified-Since 和 Last-Modified 匹 配 ， 则 返回 304 
啊 应 ， 即 内 容 没 有 变更 ， 使 用 本 地 缓存 。 此 处 可 能 看 到 了 Last-Modified 是 
当前 时 间 ， 不 是 商品 信息 变更 时 间 。 商 品 信息 变更 时 间 由 商品 信息 变更 
时 间 、 面包 导 变 更 时 间 和 品牌 变更 时 间 三 者 决定 ， 因 此 ， 实 际 应 用 时 应 
该 取 三 者 中 最 晚 的 时 间 。 还 有 一 个 问题 就 是 模板 内 容 可 能 变 了 ， 但是， 
商品 信息 没有 变 ， 此 时 使 用 Last-Modified 得 到 的 内 容 可 能 是 错误 的 ， 所 以 
可 以 通过 使 用 ETag 技 术 来 解决 这 个 问题 ，ETag 可 以 认为 是 内 容 的 一 个 搞 
要 ， 内 容 变更 后 摘要 就 变 了 。 


3.GZIP 压 缩 
修改 nginx.conf 配 置 文件 。 


gzip On; 

gzip min length 4k; 

gzip buffers 416k; 

gzip http version 1.0; 

gzip proxied any; 

# 前 端 是 squid 的 情况 下 要 加 此 参数 ， 否 则 squid 上 不 缓存 gzip 文件 

gzip comp level 2; 

gzip types text/plainapplication/x-javascript text/css 
application/xml; 

gzip vary on; 


此 处 指定 数据 至 少 4k 时 才 进 行 压缩 ， 如 果 数 据 太 小 ， 则 压缩 没有 意义 。 


至 此 整个 商品 详情 页 逻辑 就 介绍 完了 ， 一 些 细 市 和 运 维 内 容 和 需要 在 实际 
开发 中 实际 处 理 ， 无 法 做 到 面面俱到 。 


本 章 内 容 节选 自 笔 者 的 开源 电子 书 《 跟 我 学 OpenResty (Nginx+Lua) F 
发 》 第 7 章 ， 相 关 基 础 知识 可 扫 二 维 码 进行 参考 。 
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